April 2018

Bug of the Week: NSWindow beginSheet: presents wrong sheet

Welcome to our ‘Bug of the Week’ special. We highlight bugs in Apple’s systems affecting developers that are of special importance or just unbelievably bad. Here is the first one:

Bug ID 36706596: NSWindow beginSheet:completionHandler: presents wrong sheet

This basically amounts to the fact that the -[NSWindow beginSheet:completionHandler:] API can present the wrong sheet, not the one you are passing in, but another sheet that was previously presented, which is quite insane. The issue is solved in 10.13 but still present in the most recent updates to prior releases.
Debugging this issue was a nightmare around here and cost us several days because the result is so unbelievable and we were searching for possibilities of our code being broken instead of ‘beginSheet’ just showing the wrong sheet.

So, if you are trying to end sheets presented with -[NSWindow beginSheet:completionHandler:] with +[NSApp endSheet:] instead of the new method -[NSWindow endSheet:] your users on older systems might be in for a surprise. Best search all of your codebases for ‘NSApp endSheet’ to be sure.

Got a showstopper bug to share or found something breaking in unbelievable ways in Apple’s systems? Comment below and we might select your entry for the next ‘Bug of the Week’ feature!

 Tidbits: Apple Releases new OS betas, Xcode moves to clangd, Swift Tip: In-Place Map

Its random-tidbit thursday:

• Apple has released the second betas of macOS 10.13.5 and iOS 11.4, but the release notes are still extraordinarily boring. We are still waiting for a new Xcode beta with Swift 4.2.

• Apple seems to be moving Xcode from using libclang to clangd. What could this possibly mean for developers? One the one hand, Apple’s commitment to improving ‘clangd’ could mean improved ObjC&Swift support in other IDEs using clangd, like VisualStudio Code. One the other hand, if Xcode gets support for the Language Server Protocol, it could become easier to add support for other languages to Xcode.

• The objc.io Swift Tip Of The Week explains us the benefits of using mutation in general and in-place map in particular – check it out.

Kotlin/Native Plugin for AppCode Released

Hot on the heels of the AppCode 2018.1 Release, JetBrains have published a plugin for their AppCode IDE that integrates with Kotlin/Native. Kotlin/Native allows completely interoperability between Kotlin on one hand and Swift or ObjC on the other hand, which obviously enables some interesting things for writing cross-platform apps. Kotlin/Native is now featured on our cocoa languages page along with all other languages that allow interoperability with Swift or ObjC.

 Rumour: Apple plans to unify iOS and macOS via ‘Marzipan’ and move from x86 to in-house ARM chips

Unlike the rest of the internet we see little point in endlessly talking about things that are just rumours and not facts.
However, if there is something behind all this, the impact for Mac developers would be enormous – as numerous sites have been reporting in the past few weeks, Apple may be planning to unify iOS and macOS via their ‘Marzipan’ project as well as move their line of Mac computers from Intel to in-house ARM chips.

While this is all speculation at this point, rumours of Apple moving their Macs to ARM have persisted for many years now and fit well with what Apple actually wants: thin devices with long battery life and a high-profit margin. A switch to in-house ARM chips would totally make sense on this front, enabling Apple to make even higher profits on some even more desirable devices. However, there are downsides. While ARM chips may be able to compete performance wise with the quite slow chips in the Macbook/Macbook Air notebooks, we doubt they could replace high-end iMac chips the chips in a hypothetical ‘Mac Pro’. While Apple could move just some models over to ARM, this would make the transition even more burdensome. The performance problem is made worse with the fact that one would undoubtedly need some kind of x86-emulation to run ‘legacy’ binaries. Apple already switched chip architectures twice, from 68k to PowerPC (mid 90s) and from PowerPC to x86 (late 00s) and this has always been very cumbersome for developers (needing to re-write all their apps) and users (putting up with slow binary-emulation). But in both of these cases, they actually migrated to a much faster platform, which made a clear gain visible to everyone, and made binary-emulation workable. If they now switch to a CPU-architecture that is actually slower, we see little reason to stay on the platform. Interestingly a move to ARM would be much easier if their development environment was based on a JIT, like Microsoft have long propagated with C#. The native-compilation model that served them very well to keep the iPhone ahead of the competition performance-wise, may now be a hindrance.

On the topic of ‘Marzipan’ we are even more sceptical. The good part here would be to finally have some Framework/API news for Mac developers. Cocoa has accumulated a lot of cruft over the decades, and while Apple took the chance to make come improvements on iOS with UIKit, they probably didn’t go far enough and never did make it back to the Mac. The pain is even bigger for Swift developers, the sometimes cumbersome integration with ‘legacy’ ObjC APIs is probably the biggest drawback of using Swift. We’ve been waiting for a ‘revolution’ or at least a larger evolution concerning Cocoa for years, and this ‘Marzipan’ could mean just that. However, the very idea of merging Mobile and Desktop interfaces on any kind of level strikes us as extraordinarily dumb. The futile attempt to merge something which does not belong together has cost Microsoft billions during their Windows 7 / Mobile escapades. The fact that Apple has thus far kept the Mac and iOS separate and each working as it should has been a major selling point versus competing devices that are confused about what they actually are. More concretely, we can’t imagine it being possible to create a GUI framework that actually works great to support both touch-based and mouse-based input as well as screen sizes ranging from 4 to 40 inch.

Disagree? Looking forward to totally rewriting your apps for ARM-based Macs based on a UIKit-gone-fat? Let us hear your thoughts in the comment section!

EDIT: Apr20: There may be hope after all. Indeed, premature rumourization is the root of all evil. But it keeps the internet alive 😉

AppCode 2018.1 Released

Over at JetBrains they have released AppCode 2018.1, which is probably the most important alternative IDE to Xcode. There are far too many improvements to list here, including some Swift 4.1 support and support for RxSwift, which is quite cool. AppCode looks very very convincing on the feature-front, but the interface is so ugly Windows-like and nothing like a proper Mac-app as far as look&feel is concerned, that we couldn’t bring ourselves to actually use it. Even for a Windows-app the UI is bad, they really need to hire someone with user interface design experience, or at least someone with a sense of taste. But if Xcode continues its recent deterioration (we nominate it for our ‘Bug of the week’ feature for silently destroying a XIB file during refactoring just yesterday), AppCode may be the only way to go.
AppCode is listed on our apps & tools page along with a few dozen other essential apps for mac&iOS developers.

Tip Of The Week: Swift Local Computed Variables by objc.io

The guys over at objc.io are posting Weekly Swift Tips on a clockwork schedule – this week they explain how ‘local computed properties‘ can be used to speed-up code where variables that can be expensive to compute are not used in all branches. This seems like one of the first things any optimising compiler should take care of (doing calculations only when they are actually needed), does anyone have any hard data on whether the Swift compiler really does not figure this out on its own? How about other languages and compilers?

macOS 10.13.4 Released with eGPU Support

macOS 10.13.4 has been released after a lengthy-beta test. The user-facing release notes are here and the developer release notes are here.

There seem to be little changes of interest to developers (except bug fixes), with the notable exception being eGPU support. Apple’s apparent reversal of their complete disregard of everything that requires a GPU could be a game-changer for developers in the Gaming, Cryptocurrency, VR, 3D, Pro and Video sectors. Now if they’d just update their stone-age OpenGL drivers and start supporting the cross-platform industry standard Vulcan.

One other interesting thing is that ‘iMessage in the Cloud’ was again dropped again just before the final release. Originally scheduled for iOS 11/macOS 10.13, ‘iMessage in the Cloud’ has been present in every OS beta release for the better part of a year now, but was always dropped in any official release. Is this a sign of Apple’s rumoured push of software-quality instead of releasing beta-quality stuff or just a sign that they are even less able to get their act together with anything software-related than in the already poor past few years?

Swift 4.1 Released

Swift 4.1 has been released standalone (for Linux and Mac) and as part of Xcode 9.3. New features include:

iOS 11.3 Released with ARKit 1.5

iOS 11.3 has been released with many changes including some headline useless stuff like ‘Animoji improvements’. Interesting changes for developers include:

  • Support for ‘ARKit 1.5’. While there has been a lot of hype regarding AR, we are still waiting for an AR-killer-app. Maybe AR really needs accompanying glasses for its breakthrough
  • Other notable changes include data privacy improvements, seemingly in preparation to comply with the EU’s General Data Protection Regulation. If you have a website or app you should take this as a call for action, so you don’t become liable come once the GDPR comes into effect on 25. May.

You can find more information in the developer-release notes but it seems there are mostly bug-fixes.

Xcode 9.3 Released with Swift 4.1

Xcode 9.3 has been released by Apple. Interesting changes from the release notes:

  • 32-bit support is dropped. This is about time, since macOS has only supported 64-bit Macs since 10.7 (2011), Apple hasn’t offered a 32-bit Mac since 2007 and there were only a handful of 32-bit Intel Macs ever sold to begin with. Makes one wonder why Apple ever bothered with 32-bit Intel anyway.
  • the new energy organizer shows information about your iOS apps using ‘too much’ energy for apps distributed on the (iOS) App Store and Testflight
  • The debugger on macOS now requires the entitlement com.apple.security.get-task-allow to attach to apps. Apple seems to move in a direction where macOS is locked-down and you can’t debug random processes anymore. We foresee a lot of pain for low-level developers and security researchers.
  • Code-folding is still only working rudimentary, making the Xcode 9 series quite unusable
  • A lot of improvements for code coverage and new tool for parsing code coverage output, xccov.
  • Full Swift 4.1 support. We are detailing the Swift 4.1 changes in a separate post

Generally, Xcode 9.3 brings larger changes than Xcode 9.2 (release notes here) and 9.1 (release notes here) that mainly saw bug-fixes.