Publishing desktop apps

[richmond62]

Out of interest, Craig, this morning I downloaded the latest version of 'BetterBird', a 'ThunderBird' email client 'outgrowth', that is not notarised or anything else, and got the 2 'scary' dialogues as per my earlier demonstration with my Devawriter Pro.

https://www.betterbird.eu/

They seem to have a fairly high amount of usage, so it obviously is not putting quite a few people off.

[stam]

While Stam and Richmond hammer out their differences, can I ask again if by distributing standalones am I violating, if not the law, ordinary practice?

In other words would anyone at all look askance at my doing this?

I wanted, a while ago, to make a mobile app for private distribution, without notifying anyone officially. I was told this was not really possible. I assume because one cannot just send a standalone that will run on ones phone, as is possible to another desktop.

But that begs the issue of notarization, no?

Craig

Hi Craig, I think phones are much more strictly regulated - I think you can still side-load apps on Android but don’t think you can do that on iOS without a developer profile (the £79/year I mentioned above), but perhaps I’m wrong. Do you have in mind if it’s for android, iPhone or both?

As to the friendly banter with Richmond that’s all it is, no hammers involved!!!!!

[richmond62]

https://www.youtube.com/watch?v=h8Su-exNufQ

[jacque]

Stam us right, you can't sideload apps on iOS. You can on Android. He's also correct that notarization is for security reasons. I follow malware reports and Mac is no longer as immune to malware as they want you to believe. An emergency update a couple of weeks ago fixed a very bad attack that couldn't be detected by virus apps. Apple is trying hard to keep it's reputation for safety but it's getting harder. The requirement for notarization/stapling is an attempt to keep that reputation unsullied. I expect things to get worse as OS X gains a larger attraction to malware authors.

The method you described is one of three ways to bypass Gatekeeper. The other two involve going to system prefs after the warning and allowing access there, or running a terminal command. The fact that Apple allows bypass indicates that it agrees you should have some control over the machine but they make it harder for non-technical people to get an infection. Most Mac users aren't like us, they get a Mac because it's advertised as easy to use and very safe.

You are free to ignore the rules as long as you are willing to explain how to bypass Gatekeeper to the uninitiated. They may not trust your app though, which is the whole point.

[jacque]

I am wondering, though, about those scary things. Is it that all the other instances of my work is run on my own network? And is it that the few nice apps I wrote for others never had an issue because they were simply run on a personal computer?

Your Windows users won't have this particular problem of course. Nor will Mac users who run an older version of the OS. The launch challenge is the same on personal computers or, I assume, on business machines. If your apps were installed before notarization was implemented then they will continue to work for all updates. But a new, different app will trigger the challenge when first installed.

[dunbarx]

Jacque.

If your apps were installed before notarization was implemented then they will continue to work for all updates. But a new, different app will trigger the challenge when first installed.

Do you mean an updated version of the standalone? These all have different names, though they only differ as in "xxx300" and "xxx301". But those are different names in any case. My last updated standalone was last week.

Six users access the latest standalone version from a server. To me it makes no difference since I work entirely in the IDE.

I think I asked you years ago what it would take to offer a scheduling app for both IOS and Android to about 70 users. We all share the right to use two golf carts and it would be nice to be able to "reserve" them in an orderly manner. Right now we have a sign-out sheet.

We keep losing the pencil.

But this is not nearly enough enticement for me to learn how to go mobile properly, even though the actual stack would be simple.

Craig

[jacque]

MacOS identifies app by the bundle ID. If you keep that the same, the display name doesn't matter and your updates will continue to work. The bundle Identifier is the last entry in the Mac pane of standalone settings, and has the format "com.company.appname".

It isn't as hard as you might think to build for mobile, at least once you learn the idiosyncracies of the two platforms. Resizing the stack to fit the current device is probably the main one. You'd need to decide whether to use a resizeStack handler or fullScreenMode with some adaptations.

Distributing the mobile app on Android is pretty easy. Put it on a server and let users download and install it. They will need to give permission to allow downloads from "unknown sources". On older Android devices that's a global preference in system settings. On newer devices it is pretty easy to agree to the dialog box that appears.

On iOS you can't distribute an app except through the App Store unless your organization has a corporate account. That will require a developer account, a fair amount of tinkering in the developer console, and a number of other things. If your company has a corporate account the rules are more flexible about what is required for your app and what APIs it can acccess.

My suggestion has long been to tell people to get Android phones, but no one ever listens to me. The US is largely an iPhone audience. They don't know what they're missing.

Addendum: There is one other way to distribute to iOS if you only have a few users (less than 100 I think.) You can distribute off your own server as a test app. (That's what my AirLaunch app helps with.) You'd need to get the UUID of each user's phone and create a development profile for those phones only. After that, no need to go through the App Store for distribution, though you still would need a developer account. You can add more users up to the limit at any time, but you'll need a new profile and a rebuild each time you do that. Another way is to use Apple's TestFlight feature, but that involves more tinkering in the developer console.

[dunbarx]

Jacque.

Thanks, as usual.

I have always had a developer account, over 30 years. It makes me feel important.

I will take a peek at AirLaunch. The stack I would make for the sign-up thing could be pretty well locked down before distribution, so I would not need to tinker with it like I do with my business gadget, where I update for various reasons about three times per month.

Craig