First of all, I know about this: Licensing Technology for OS X applications?
But, since it was posted so long ago, that almost all answers point to dead urls, I think its time for a new question.
I am researching options on frameworks for license-key registration for OSX cocoa apps. I want to know what is out there, that supports Elliptic Curve Cryptography and is released under MIT or something similarly permissive as a license.
Currently, I've found just this (Watchdog): https://github.com/konstantinpavlikhin/Watchdog
But there are no reviews about it, nor does it seem to have much traction at github.
I use EllipticLicense for ECDSA-based license keys (the link is my fork of an abandoned project). It doesn't do online activation or validation or provide any UI, but it's simple and the validation is cross-platform, which is what I need.
I'm keeping an eye on DevMate by MacPaw as an all-in-one solution, but they're not out of beta yet.
I know it's not what you're asking for - but I can't see the purpose in super-complicated key generating algorithms when users can simply distribute valid keys they've bought from you through the various, well-known means (web sites, offline apps/databases of license codes)..
It might pay off to rather spend the time in developing cool features and building a strong user-community that's willing to support your app.
Related
The readme.md at https://github.com/NativeScript/windows-runtime says that the Windows runtime for Nativescript is in proof of concept stage, and then lists what I understand to be very deep language features that are not implemented yet.
The tone on the https://www.nativescript.org/blog/nativescript-runtime-preview-for-windows-10 announcement seems a bit more enthusiastic about the current feature set.
Being able to use Nativescript on Windows Phone (and any other platform) is incredibly appealing.
TJ, a core team member, recently posted on the forums about this:
Hey #NezzaGrey,
Thanks for reaching out, and awesome that you’re liking NativeScript :smile:. >Straight to the point though—we’re not actively working on UWP support because >1) it’s a ton of work to add a new platform and commit to supporting that >platform indefinitely, and 2) we’re not seeing nearly enough demand from our >community to justify taking on that work.
That doesn’t mean that UWP support in NativeScript will never happen, but it’s >not coming in the short term because we’re just not seeing the demand. That can >always change though. I’d encourage you to add your use case to the GitHub >issue open for adding UWP support in NativeScript: >https://github.com/NativeScript/NativeScript/issues/254. Yes, the issue is >somewhat ancient, but we really do pay attention to well-thought-out comments >during roadmap discussions.
I’ll note two other things. First, our initial work on making a Windows runtime >is completely open source and available on GitHub: >https://github.com/NativeScript/windows-runtime. We’d love to have community >?>help to make the new runtime a reality.
Second, one option you have is to build your iOS and Android apps with >NativeScript and Angular, and to use our code sharing approaches (see ?>https://www.nativescript.org/blog/code-sharing-between-web-and-mobile-with->angular-and-nativescript1) to share your Angular code with other apps. You >could take that approach to share Angular code between your NativeScript apps >and your UWP apps if you use something like Electron. This approach isn’t >ideal, as you’d probably prefer to build a completely native UWP app, but it’s >something to consider if you’re open to using Electron.
Anyways, hopefully you found some of this helpful. If you have any other >questions feel free to follow up.
Source: https://discourse.nativescript.org/t/windows-uwp-support/2659/3
I am trying to evaluate whether Xamarin would be a good option for my project. The project is a large, complex app for Android and iOS with a lot of client-server communication. The user interface is a major focus and has to be really fast and smooth. Also, we plan to make large use of UX graphic effects (comparable to the Spotify app).
For now we are planning to go for two separate native apps using Java/Objective-C. However, the possibility of cross-platform code sharing would be very convenient for us of course.
Most opinions I've heard so far say that Xamarin - although far better than HTML5 apps - cannot match the UX of a native app. Also, I tested the following applications made with Xamarin (on Android):
Rdio
MarketWatch
Busch Gardens Discovery Guide
Sqor
Storyo
From my impression, none of them could quite match the speed and smoothness of a good native app.
If our focus is on a top notch user experience, would Xamarin really be a viable option? Can it really match a native UX? I am particularly looking for opinions from developers who have experience with large and complex cross-platform Xamarin applications. A few critical voices would be very helpful.
Thank you a lot!
I'm on the Rdio mobile development team, so I can make some personal reflections from that standpoint.
Xamarin allows you to write native applications in C#. Any slowness, jankiness, ugliness or bad-appiness usually has nothing to do with the Xamarin layer itself.
You save some time being able to share core business logic between your different clients, but you're still writing the UI from scratch, specific to the platform. You're just writing it in C#.
But while you save that time, you're spending it in other ways. All of those SDKs you want to use probably aren't compatible with Xamarin out of the box. You won't be pod install'ing that iOS framework, and you might be reinventing the wheel for handfuls of things. Xamarin takes advantage of the NuGet repo so you have a library of components that handle many of the things most people need (Analytics, Testing, Facebook SDK, JSON parsing, Database, etc etc) but it doesn't cover everything. And it certainly doesn't cover stuff that's out the day of an Apple or Google product announcement.
Any 3rd party code that you do want to import into your project will be done through writing custom bindings. While not usually difficult, it is time consuming. Xamarin has a team of people that specialize in assisting you in this. This fact speaks to the process being messy at times.
So while the slowness, jankiness, ugliness or bad-appiness probably isn't the fault of Xamarin, it might be the fault of you spending time in places you normally wouldn't, or not being able to take advantage of features you normally would. If that 3rd party partner SDK is giving you problems, your troubleshooting may take twice as long because there's a layer that you don't control.
UI is a wash. You're writing it from scratch anyway.
Business logic is shared. Depending on the app that might be a win if you architect your application to take advantage of it.
Compatibility / bleeding edge ability will be lacking. That might not matter to you at all, or you might be the person wanting to take advantage of that hot new API in the next OS release the day it's announced.
My personal thought, without knowing specifics, is if you want to build an application that you plan on being around years from now, and that will take advantage of the latest and greatest, I'd tell you to write natively for each platform. Unless you can really see huge gains in sharing that business logic the upfront gains are minimal. Or if you really like C#.
Xamarin uses native controls. So you design a fully native UI per platform. The users can't see that your App is made with Xamarin or Java/Objective-C.
There are sometimes performance issues in conjunction with the platform independent UI wrapper Xamarin.Forms. But you're not forced to use it. When you have still performance issues in your Xamarin.Android or Xamarin.iOS app then you produce them in your code.
There are benchmark results for Android apps comparing Xamarin.Android and Java apps: Does anyone have benchmarks (code & results) comparing performance of Android apps written in Xamarin C# and Java?
As you can see Xamarin's internal performance became better and better over the time.
Conclusion: Yes, you can write smooth native Apps using Xamarin.
Silicon Realms (Digital River - Armadillo) used to have a Mac application protection/trial builder. They discontinued it this year most likely due to Mac App store not allowing 3rd party protection mechanisms or trials. Does anybody know of alternatives for creating trials and generally wrapping apps for copy protection which will not be sold on the app store? I am not expecting iron clad solutions... just simple copy deterrents and 30 day trial mechanisms.
The only solution I've found is ExeShield. No idea how well it works, but since I just discovered that Silicon Realms discontinued their program I'll probably have to go with that.
Apple is working harder and harder to get you into their store - and take their 30% of the gross off the top. Eventually Apple will do anything, legal or no, to make sure that they make more money out of your program than you do...
I'm aware this isn't exactly a programming question, but it directly impacts our developers and the code we're assigned to write. If there's another SO-like forum where this could be better posted, please let me know and I'll take the question down from here & post it there.
Our work environment is a couple of developers creating (20-30%) and maintaining (lion's share) legacy software for factory production floor and test workers to use to calibrate or test the equipment the company sells. We've implemented a very simple Google form based bug reporting page, but we're already running into problems of scale (approx 40:1 them:us and lots of old-old buggy software that we didn't write). The company has tried using Bugzilla before my arrival with little success, the factory folks were apparently intimidated by it and wouldn't use it. However, they seem to like the simple Google form and the wizard-like steps to file a bug or request a feature. We're currently manually cutting & pasting their bug/feature requests from the Google form spreadsheet into Trac, and manually tracking the bugs/feature requests on a white board with magnetic bug cards. We're only a few weeks into this system and it's already showing it fragility and lack of scalability.
Ideally we'd have a Windows >= XP web or desktop client that would provide:
Simplified bug reporting, a Wizard like approach seems to work well
Customizable for our software packages (like drop downs for each)
Bugzilla or Trac integration
Standard bug tracking features developers and management can use
I've found the winners of the "Make Bugzilla Pretty" contest, but coming from a pure software house where we just used straight Bugzilla out of the box, I'm unclear on how to configure and install these skins. Obviously I can figure this out but don't want to go down that path if it's not going to solve our basic problem which is non-technical people reporting bugs.
TaskCompiler, found on the Bugzilla wiki site seemed like a candidate because it talks to both Bugzilla & Trac, but their sales page is offline and the site hasn't been updated since 2012 and I'm unsure as to their viability.
I'm certain we're not the first production facility to run into problems like this, I'm looking for recommendations to help solve both our scalability as well as-ease-of-use problem.
Another thought that occurs to me is a GAS script to push our current Google forms based bug reports into Trac or Bugzilla.
Edit: The decision between Bugzilla/Trac seems to have been made for us. I'm exploring options for using Trac here if you want to follow along.
And/or: do I need one?
I've recently started using FogBugz for my hobby projects, and I'm very happy with things so far. Having read more about it, especially the evidence-based scheduling, I'd like to start using it for my PhD as well. (Heh; something tells me my supervisors won't be opening tickets for me, though.)
Last night I stumbled onto TimePost, which looks like a tidy app that doesn't do much but could be a real bonus to logging my time in FogBugz effectively. I tried looking around for similar apps but came up a little empty-handed. Are there any other FogBugz clients that you've used and recommend for Mac OS X? Or are you happy with the web interface?
The official answer is no, there is not a dedicated Mac client, other than Safari :)
There's a command line version that runs on Linux, Windows, and Mac.
There are also plans for an iPhone version although I'm not technically supposed to announce features before they are done or even spec'd so pretend I didn't say that.
I recently spotted this one which looks quite nice for additions:
http://manicwave.com/products/tickets
I'm happy with using the web interface. I've used Fluid to create a custom browser for it, and even gotten some help making a pretty icon.
We recently released a new Fogbugz client software for Mac, maybe you are interested to give it a try, http://lithoglyph.com/ladybugz/
I remember reading that there was a client in development, and I believe they're still looking for beta testers. See this URL
http://support.fogcreek.com/default.asp?fogbugz.4.24403.0
Shameless plug here, but you might wanna check out QuickBugz --- it is a lightweight program that integrates into your status menu. http://www.quickbugzapp.com
I have been very happily using the Tickets program from Manic Wave for a few weeks now. it provides a very fluid experience. I am using it in a pressure cooker of doing a competition entry in my odd hours around my day job.
Tickets makes it incredibly easy to create lots of small cases and juggle them between different milestones. I particularly like its outline view which helps when doing task breakdowns into sub-tasks.
Being a long way from the Fogbugz servers, in Western Australia, the speed of a searchable local interface is very much appreciated.
The UI has a lot of nice little Macisms such as mouse over a milestone and see the hours summarized.
Support has also been very prompt and comprehensive.
I don't think there is any other such Mac tool. I've never found the web interface too bad personally.
I don't know of any native tool, but like Matt I am pretty happy with the web interface.
The beta of Safari 4 and SSB feature is a pretty good option...
I found using a Mac browser w/ the screen snapshot and search engine add-on to be very useful. I think what you are saying is that it can be hard to edit your timesheets, but that is part of the web design.
I've just released Bee, which is a Mac client for FogBugz. (It also pulls in your tasks from GitHub and JIRA.)
It offers several benefits over the web interface and is designed to be simple, fast and elegant. You can check it out at: http://www.neat.io/bee/fogbugz.html