beaTunes News

Catalina will be upon us this Fall, which means that iTunes will be no more (R.I.P.). But that's not the only thing that will change. According to Apple:

Mac apps, installer packages, and kernel extensions that are signed with Developer ID must also be notarized by Apple in order to run on macOS Catalina.

This has a number of consequences.

First of all, this may increase security for users. A notarized app may be less able to carry out an attack. And users will be able to distinguish between notarized and unnotarized apps. If I am not mistaken, it might also give Apple a kill switch on any such app, at least when you first try to run it. Because as it turns out, macOS 10.14 and later phone home when first running a notarized app. Additionally, this gives Apple unique data about which software was installed on which IP address at what time. So for the user there are some privacy concerns and maybe some security benefits.

What does it mean for developers?

Frank Reiff recently wrote a lengthy post about all the trouble he faced when trying to notarize an app. It took him 5 days to get it all to work. In the end he concludes:

As a long time Mac developer (since 1994), however, I can’t help thinking though that the security people at Apple would have done better ironing out the bugs and limitations of the sandbox to get it work properly and be less of a nuisance, rather than adding yet another security approach.

If early reports about Catalina are to be believed, it looks like there are so many people working on Mac security that they have to roll out new security features at each release, whether they are a net benefit to users or not. Perhaps, these people could be tasked with making macOS great again instead?

AFAIK, Frank is using XCode and ships native apps. For beaTunes things are a little different, as it uses Java as runtime. So far Oracle (or anybody else I know of) has not shipped a Java runtime that has been compiled against macOS SDK 10.9 or later and the hardened macOS runtime. Additionally, Oracle's Java executables are not signed with suitable signature algorithms (see Bug JDK-8223671 for a detailed list of notarization failures). All these are requirements for notarization. There is no way for me to ship a notarized version of beaTunes before they are addressed and unless I want to roll my own version of Java (I don't!!), I simply have to wait and hope that someone at Oracle will take pity on Mac devs.

Not a pleasant situation to be in.

Update 8/6/2019

It turns out that notarizing a Java app that bundles Java 11 is a bit painful, but absolutely possible.

Labels: Apple, Java8, Notarization

This update fixes a couple of issues, most notably a potential stack overflow on Windows. To counter issues with the Amazon integration, some error messages have been revised to be more precise and browser-based alternatives have been enabled to view Amazon charts. I'm aware, these are certainly not ideal solutions, but for the time being the appropriate step.

On another front, Apple has apparently decided to drop the automatic export of the iTunes Library.xml file from their macOS 10.15 iTunes incarnation, dubbed Music.app. This is an issue as beaTunes still relies on the file. I'm actively working on resolving this and am confident there will be a solution before macOS 10.15 is released to end-users.

As always, you can download the new version from the download section of the website.

Changes in 5.1.14

• Fixed potential stack overflow on Windows (MediaKind).
• Provided browser-based fallback for failing Amazon charts.

Labels: Amazon, Apple

As you might know, a new version of Apple's operating system macOS named Mojave is going to be released very soon. Be advised that beaTunes is not optimized for Mojave yet. Specifically, there is no integration with Mojave's dark mode and AppleScript may cause some headaches.

While dark mode integration is purely cosmetic (just use the 'dark' theme accessible via beaTunes' general preferences), AppleScript issues may be more problematic. When you are using beaTunes to maintain your iTunes library on macOS, you are effectively letting beaTunes control iTunes via AppleScript. Mojave may introduce a new security mechanism called AppleScript Sandboxing. This means that, before an application is allowed to control another application via AppleScript, the user is asked whether that's OK. This is most certainly not a bad thing, but Apple's implementation is still fairly new (not to say immature) and has been ridiculed a bit, simply because it reminds people of an old Apple commercial (with reversed roles).

A couple of people in the indy software world have voiced some legit concerns and criticism. Here's a little reading list:

• Felix Schwarz: macOS Mojave gets new APIs around AppleEvent sandboxing – but AEpocalypse still looms
• Daniel Jalkut: Apple Events Usage Description
• Dave Nanian: macOS Mojave: Opening New Vistas in Security for Mac Users
• Paulo Andrade: Apple Events And The State Of macOS Automation
• Paul Kim: Hazel and the AEpocalypse
• Doug Adams: Mojave Security

What does this mean for beaTunes?

For now—not a lot. I will wait until the final macOS Mojave version is released before making changes, simply because this security mechanism seems to be too much of a moving target. After the dust has settled, we will see what's the best way to proceed.

PS: If this does not scare you or you have trust in dot-0 versions of Apple's operating systems—by all means, please take beaTunes for a ride and report on help.beatunes.com what problems you ran into!

Labels: Apple, AppleScript, macOS, Mojave

Here's how Apple reacted to my last OS X 10.10 bug report:

That's right:

No plans to update Yosemite.

But let me start from the beginning... and yes, this is a little bit of a rant, something I felt I needed to get off my chest.

I develop and sell a small music app for Windows and OS X. Software veterans know, maintenance is an integral and probably the largest part of the development process. Since the software runs on customer machines, it's essential that it sends home crash reports (after asking for consent) so that I am aware of those really nasty, hard to reproduce bugs. These crash reports can easily be grouped by OS version, app version and probably most importantly, offending frame. This lets me prioritize and decide, on which bug I should spend the most time. The bug that eventually led to Apple's response from above was identified this way (rdar://22948498). It's one of the most frequent causes for crashes of my app on OS X 10.10. And it will never be fixed.

Because my app is written in Java, most crashes (let's define a crash as an event that produces a crash log) are caused either by the Java Runtime Environment (JRE) or by the OS. Solving JRE problems is not easy, but doable: The JRE is open source, there is a public bug database and there are a bunch of mailing lists that let me talk to Oracle engineers and other involved parties. Plus, and now we're getting closer to the actual topic of this article, I can freely choose which version of the JRE to ship with my app. Heck, I can even patch it myself and ship a custom OpenJDK version, if I want to. Not that that is typically a great idea, but still...

Solving OS problems is much harder. Neither OS X nor Windows are open source, there is no official and open bug database (Open Radar is great, but not official), and I don't get to choose the OS version my customers use.

But, you may say, you can require users to use OS version X.Y.Z in your system requirements blurb.

Yes. Indeed, I can.

But remember what I wrote about maintenance being part of software development? De facto, system requirements only shield you from old OS versions. What happens, when the customer updates her or his system, because the new UI is so much prettier? Or, as illustrated by Apple's response, when the OS manufacturer decides that it is no longer fixing certain bugs in its "old" OS (released 7/2014!) and actively urges customers to update their systems?

Why can Apple afford not to fix its OS? Tweet

From Apple's point of view, 10.11 is the bugfix for 10.10. And it's free as in you-already-paid-extra-for-the-hardware. So users just need to install this free upgrade, no need for Apple to fix the 10.10 branch, and everything is fine. Or is it not?

It is not.

Twitter is full of people bemoaning the fact that Apple is semi-forcing OS upgrades upon them. And they suffer when essential applications don't (yet) run on the new OS version, the vendor decides not to support the new OS at all, or the app is old but paid-for and now requires a paid upgrade.

What does Apple do about this? It's almost comical. OS X moves known incompatible software into a separate folder. Out of sight, out of mind. Problem solved. Frankly, I have my doubts the mechanism works well for anything but software built for the wrong architecture—be it 32-bit or PowerPC. If you really want to know, whether some app runs under a certain OS version, you might want to check a site like roaringapps.com.

But let's be fair. I'm sure that Apple tries hard not to break compatibility. Unfortunately, trying is not enough. Users and app developers inevitably have to deal with software that simply does not work anymore. If this happened every five years or so, it wouldn't be a big deal. But Apple likes to release often, push innovations out the door, and throw away legacy code. A new OS version is presented almost every year. So we are facing this problem quite frequently.

How much does a free OS upgrade really cost? Tweet

To be clear: I'm not saying that short release cycles are necessarily bad—they have their advantages. But contrary to what Craig Federighi claimed in 2013, the yearly OS X upgrades are not free. A price needs to be paid for each new version. Either by app developers, who have to spend a lot of time on making sure that their apps still work, or by users, who loose perfectly good apps or have to pay for upgrades. And that's why I'm so annoyed that Apple won't fix that 10.10 bug mentioned above. The price for that bug is paid by us, because it only leaves us with the unfortunate choice between occasional app crashes and an OS upgrade with associated hidden costs.

Most likely, Apple will announce another free upgrade for OS X at this year's developer conference (WWDC).

Will you upgrade once it's released? How much will it cost you?

Labels: Apple, El Capitan, OS X, Yosemite

Back in December Apple made clear that it does not want Java apps in its store. Now the company took the next step: non-MAS (Mac App Store) apps are banned from the Apple Design Awards (see Ars Technica).

I fail to recognize how using a particular sales channel is a sign of good design, but I'm sure Apple knows what it's doing to boost sales. Its sales.

Labels: ADA, Apple, MAS

Back in December I wrote this open letter to Ron Okamoto (who?). A little later someone from Apple Developer Relations actually tried to contact me, to chat about the letter and to get some more feedback. Getting in touch has been rather difficult due to different time zones, but eventually - thanks to rather impressive persistence - it worked out.

I have to admit that I'm a quite surprised and a little impressed that somebody at Apple actually made the effort to get in touch. I even got a little 'present'. That is pretty cool.

Unfortunately, I was told that the OS X software listing will go away eventually. And that still means that I will lose roughly 30% of the traffic to my site.

And while I really appreciate the touchy feely part of reaching out to developers like me, that is still decidedly uncool.

Labels: Apple

Dear Ron,

Thank you for informing me almost three weeks ahead of time and four days before Christmas, that you are going to get rid of the source of roughly 30% of the traffic to my website. Yes, I'm talking about the Mac OS X Download site (http://www.apple.com/downloads/macosx/). This little directory, initially set up so that users could be convinced that there is software for OS X at all, has been a great, reliable and -above all- free marketing tool - helping Indie developers like myself to get the word out, sell their applications. Cancelling the site will make it mandatory for any small dev shop to move to the new Mac App Store to have a chance at survival - even if that means being practically forced into revenue sharing with Apple and not being able to control one's own release schedule.

You say you believe that the "Mac App Store will be the best destination for users to discover, purchase, and download […] apps", and certainly the Store offers all of this. Obviously, it will also be a very suitable tool for Apple to censor content, dictate technology, and participate in developer's revenue streams.

How so?

Well, if we have learned anything from the original App Store, the approval process is a gamble which leaves the developer with no control. For small devs it is especially troublesome that the release date depends on such a great unknown. That is, if the app is approved at all.
This means developers first have to make the huge upfront development investment, during which they earn no money whatsoever, and then hope that the app is approved (in time) so that eventually they can find out, whether there is money to be made with their app at all. To me this sounds like making a hard and risky business even harder.

So what about technology? A little while ago, Apple stopped development of its own Java Runtime Environment (JRE), which is now being continued with Oracle's help as part of OpenJDK. Apple declared Java officially "deprecated". At the same time Apple announced that it would not allow apps in the Mac App Store built on "deprecated" technology. In other words, if I want to sell it in the Mac App Store, I must built it using Apple approved technology, i.e. Cocoa, Objective-C, etc. It does not matter how awesome my app is - if it's written in the wrong language, it's out.

Last but not least, the money. While a single sale via Paypal costs me a fee of roughly 4.5%, a sale in the Mac App Store costs 30% - that's more than a 650% increase. An increase that the consumer will have to pay to a fat company that already has billions in the bank.

And best of all, the precise terms under which I can or cannot sell an app in the Mac App Store aren't even publicly viewable on the developer's Mac App Store website (http://developer.apple.com/programs/mac/distribution.html). I actually have to pay the $99 membership fee to find out.

So, yes, for the consumer the Mac App Store seems to be a great thing. Obviously, for Apple it's a great thing (who wouldn't like a 30% revenue share of most software sold for the Mac?). But what exactly is it for Indie developers? What are Indie developers to begin with?

I don't think there is a precise definition, but to me Indie developers are those people who alone or with a few friends write often quite innovative software without having the backing of a huge company. In other words, these people often start creating stuff after they come home from their day job, risking their savings and alienating their families. It's also these Indie folks who tend to win Apple Design Awards.

And exactly these people Apple wants to take money from, make their schedules even more unreliable and stifle creativity through the Mac App Store corset.

Doesn't sound quite so cool and "independent" anymore, does it?

Developers writing software for Apple have traditionally been forced to rewrite stuff every couple of years, because Apple has dropped this or changed that API (e.g. think Carbon/QT and 64Bit). And given the choice between having to deal with ancient APIs forever and neat no-baggage innovation, I'm in Apple's camp. However, being forced through means of a soon-to-be dominant sales channel to use a certain technology, turns Indie developers into proprietary lapdogs. Whatever I write for that Store, I can't sell on any other platform, because of severe technology lock-in.

So to answer my own question: For Indie developers the Mac App Store in its current form is a short leash, lock-in, penalty and taxation system.

Quite the grim outlook for the new year...

Well, Ron, you might say that Apple never promised to do no evil. And I guess no-one ever said that Apple is not greedy. To me, Apple is unfortunately becoming more and more of both.

Merry Christmas,

-hendrik

Dear Hendrik,

Thank you for making the Mac OS X Download site a great destination with apps that offer users new ways to work, play, learn, and create on their Mac.

We recently announced that on January 6, 2011, the Mac App Store will open to users around the world, presenting you with an exciting, new opportunity to reach millions of customers. Since the introduction of the App Store in 2008, we've been thrilled with the incredible support from developers and the enthusiastic response from users. Now we're bringing the revolutionary experience of the App Store to Mac OS X.

Because we believe the Mac App Store will be the best destination for users to discover, purchase, and download your apps, we will no longer offer apps on the Mac OS X Downloads site. Instead, beginning January 6, we will be directing users to explore the range of apps available on the Mac App Store.

We appreciate your support of the Mac platform and hope you'll take advantage of this new opportunity to showcase your apps to even more users. To learn how you can offer your apps on the Mac App Store, visit the Apple Developer website at .

Best regards,

Ron Okamoto
Vice President, Worldwide Developer Relations
Apple Inc.

Labels: Apple