The Catch-22 of Building a Business on Apple’s APIs
blog.astropad.com
blog.astropad.com
It is some kind of dilemma, sure, because you have to decide between making your life easier by using powerful and convenient platform-exclusive APIs or staying more independent by trying to use as much generic, cross-platform foundations as possible, even though this makes your job more difficult and consumes more effort.
But it is by no means some kind of contraption from which there is no possible escape route - which is what a catch-22 entails, as far as I understand it. It's an engineering trade-off, just like all those other trade-offs that we as engineers have to evaluate and eventually decide about all the time.
It seems to me like someone wanted to use the well-known "catch-22" moniker as a catchphrase (pun intended) here ;-)
Usually demonstrated by the fact that for their specific functionality, they require a native app, and their identical Android application makes almost no money compared to the iOS app.
Not saying all apps are like that. But there are quite a few that for whatever reason, only make money on iOS.
That's not a catch-22. A catch-22 [0] is when you have contradictory requirements that are all needed but eliminate each other [Wiki example: How can I get any experience until I get a job that gives me experience?]. A hard choice or a single choice aren't a catch-22.
Sidecar is a breath of fresh air, and I hope Apple will extend it to work from Mac to Mac, much like the old Target Display mode which was unfortunately dropped from the iMac 5K. Note that iPads/iPhones have also been able to send video to macOS via QuickTime Player for years, but it is a bit clunky if you just want to use the Mac display as a mirrored iOS display.
FWIW: It was dropped from that model because (at the time) there was no way to drive a monitor that large over DisplayPort. DisplayPort 1.3 would have supported it, but that was only announced a month or so before the iMac 5K came out -- the hardware was finalized long before that.
It is disappointing that Apple hasn't added Target Display Mode back to newer models, though.
https://www.cnet.com/news/turn-your-ipad-into-a-second-monit...
A great advantage of choosing C++ as a core language is that the language (albeit syntactically/semantically a monstrosity to many) still evolves while receiving feedback from industry (i.e., features are there because complex software needs it). There's the Standard C++ Foundation [2], where big players like Google, Microsoft, Nvidia have a say.
They clearly state this themselves:
> while there are early attempts at running Swift on other platforms, how committed to that effort do you think will Apple be
They justify this scepticism with experience from trying to run Objective C code on other platforms:
> We’ve tried to port our core Liquid platform to Windows via WinObjC and GNUStep, but both attempts produced only partial success and a brittle platform that we’d be hesitant to build on for the future.
Better to build full native but rely on cross-platform architecture, design patterns, common backend/infrastructure, etc than settle for hypebeast cross-platform abstraction magic with dependencies on overburdened and leaky by definition integrations back to native SDK. The former yields all the proven benefits of native apps and strong platform vendor support with a contingency plan if said ecosystem launches a competing product. The latter leads to a world of hurt.
Specifically, the article misses the mark wrt Swift. Swift is open source and truly cross-platform. SwiftNIO, Tensorflow, and the server-side Swift projects are a great example of how far one can go assuming a willingness to invest in the language completely devoid of any Apple API involvement.
It truly seems like the next major breakthrough would be if SwiftUI could (relatively easily) be implemented for desktop Windows or *nix. Sure, the article notes people tried the same thing with GNUStep or WinObjC, but you were always truly tied to or ended up missing Cocoa, Foundation, and the Obj-C runtime. Conversely & ironically, swift-evolution, spm, and many of the most "Swifty" parts of the Swift ecosystem come to the other toolchains long before they make it into an annual Xcode release.
Even things like games can work better when they take advantage of platform-native APIs (e.g. directx on windows, metal on iOS/macOS), so either using a game engine that is well specialized for multiple platforms or using the underlying APIs directly is likely to yield better performance and playability.
Until Swift gets a Windows download link on http://swift.org, I am only considering it on the context of Apple platforms.
Subscription pricing was (and is) a major turn-off for me, particularly for something like AstroPad, which simply allows you to use the iPad as a touchscreen display for macOS.
How long should they keep backwards compatibility in watchOS - which is very resource constrained? Going back further - should they never have dropped 68K support? PPC support from MacOS?
Even Microsoft dropped 16 bit support from the 64 bit version of Windows. Before someone posts “proof” that you can still run 16 bit apps on Windows, please read the part about “the 64 bit version of Windows”.
Yes. That is why x86 became so successful and why Windows is so much loved by big corporations. Microsoft and Intel care(d) a lot about backwards compatibility - even desktop applications that were released 20 years ago usually work on today's Windows/PCs.
> Even Microsoft dropped 16 bit support from the 64 bit version of Windows.
Only in the 64 bit versions of Windows. Microsoft still sells 32 bit versions of Windows 10 if you want. In the 32 bit versions, 16 bit applications were supported for a long after. I admit that I have not tested whether 16 bit applications still run under the current 32 bit version of Windows 10 - but I consider it as plausible.
So instead of using the die space saved by removing 32 bit support and using it for some combination of increasing performance, improving battery life, decreasing die size etc they should have left it and suffered? How well is Intel’s backwards compatibility strategy working on mobile where they are basically non existent?
Also, Apple sells more devices with ARM chips than all of personal computer manufacturers combined, the performance of their ARM chips is competitive with Intel’s chips except for the server chips and they use less power. It doesn’t seem to be a winning strategy to keep backwards compatibility forever.
So backwards compatibility hasn’t exactly helped Intel in mobile - which is a much larger market than the desktop/server market. Even there PC manufacturers are trying to move to ARM for price performance and energy savings.
Yes, Microsoft still sells 32 bit Windows. But it can’t take advantage of modern processors - and by “modern” I mean even my circa 2009 Core 2 Duo 2.66Ghz Dell with 8Gb of RAM (running 64 bit Windows 10) that served as my Plex server until earlier this year.
How has backwards compatibility helped MS? Apple was able to port their core OS to 128Mb RAM/400Mhz iPhone back in 2007. Since then, they’ve ported it to everything from watches, tablets, and set top boxes. Microsoft has tried and failed in each of those markets.
> So instead of using the die space saved by removing 32 bit support and using it for some combination of increasing performance, improving battery life, decreasing die size etc they should have left it and suffered?
Removing the 32-bit instructions/registers isn't what achieves the performance and battery life improvements, those come from eliminating the RAM, cache-misses and context-switches dedicated to the 32-bit apps and that can be more than offset by not activating the 32-bit environment at all, unless it is actually needed by the user for legacy compatibility.
> Apple was able to port their core OS to 128Mb RAM/400Mhz iPhone back in 2007
Note that MS ported their core to a 4Mb RAM 36MHz Velo-1 back in 1997 and many Chinese manufacturers make low power chips like that (for DVD players, TV sets, etc.) that ship with operating systems that have exactly the same APIs (knock offs) of Win16 and Win32.
> 2007. Since then, they’ve ported it to everything from watches, tablets, and set top boxes. Microsoft has tried and failed in each of those markets.
You might want to look into Xbox, Surface, Foldable Surface the old Casio watch and what kind of boat anchor Apple's Darwin has been for realtime embedded devices like Apple Watch.
Apple was able to successfully port the Core of MacOS to phones and other products - MS not so much.
I didn’t say anything about RISC vs CISC, but Intel has had to throw a lot more money at the x86 architecture to achieve performance while keeping backwards compatibility and they have not been able to make a chip that was suitable for mobile.
Removing the 32-bit instructions/registers isn't what achieves the performance and battery life improvements, those come from eliminating the RAM, cache-misses and context-switches dedicated to the 32-bit apps and that can be more than offset by not activating the 32-bit environment at all, unless it is actually needed by the user for legacy compatibility.
That’s also logically not true. How can it not be a win to being able to remove entire parts of the chip dedicated to 32 bit instructions?
Note that MS ported their core to a 4Mb RAM 36MHz Velo-1 back in 1997 and many Chinese manufacturers make low power chips like that (for DVD players, TV sets, etc.) that ship with operating systems that have exactly the same APIs (knock offs) of Win16 and Win32.
How did that work out in the market? Also in 1997, there was a lot less cruft in Windows than a decade later.
And the XBox hasn’t exactly been a success in terms of either profitability or units shipped compared to mobile. Microsoft is busy fighting the last war. The “foldable surface” is vapor ware, the x86 based surface still has horrible performance and battery life compared to ARM tablets.
> So should Apple have kept the silicon required to support 32 bit apps in their ARM chips forever?
Yeah, I think so. One would think that Apple would have learned from DEC's mistake in this regard, but such history lessons have been lost with the age discrimination. They should not have made the decision to virtually force consumers that are busy paying rent/mortgages, car payments and putting their kids through school to update software and buy upgraded hardware that breaks apps that they, as consumers, rely upon for home appliances, automotive and online services, especially when those users have gone into debt for upwards of a thousand dollars per device. Someday there will be a transition to radically different devices (projector/visor/voice or whatever) and that would be the time to not support 32-bit. Anyway, they made the decision and there will be all kinds of consequences (with a one trillion market cap, I'm sure they can handle it but what a horrible drain on all of creation for everyone to deal with).
> How long should they keep backwards compatibility in watchOS - which is very resource constrained?
That's an esoteric cosmetic platform with almost no relevant third-party apps (just second screen notifications) yet, so no need to worry about compatibility.
> Going back further - should they never have dropped 68K support? PPC support from MacOS?
Of course they should never have dropped support for 68K or PPC, even if it just meant shipping a System 7/macOS 9.04 in an emulator in every new Mac sold, forever. If they wanted to release a computer not called Mac, then that's another story but they clearly wanted to kill off the embarrassment Jobs created back when he was still learning what happens when you consider formal-training/experience to be a handicap.
> Even Microsoft dropped
Windows' success had almost nothing to do with such technical decisions so it's not real relevant though the compatibility between releases of Windows and Office was remarkable because Microsoft did learn from the lessons of DEC (because it actually had hired much of DEC's team heh).
Because what killed DEC is leaving backwards compatibility not cheap x86 based servers and people moving to Unix instead of DEC VAX/VMS. No I am not a youngin who doesn’t know about mainframes. My first job out of college was programming VAX/VMS and Stratus VOS mainframes in C and FORTRAN.
Anyway, they made the decision and there will be all kinds of consequences (with a one trillion market cap, I'm sure they can handle it but what a horrible drain on all of creation for everyone to deal with).
You mean the same decision that they made transitioning from 65C02 Apple //s, to 68K Macs, to PPC Macs, to Intel Macs?
That's an esoteric cosmetic platform with almost no relevant third-party apps (just second screen notifications) yet, so no need to worry about compatibility.
Yes there are native apps for WatchOS.
Of course they should never have dropped support for 68K or PPC, even if it just meant shipping a System 7/macOS 9.04 in an emulator in every new Mac sold, forever. If they wanted to release a computer not called Mac, then that's another story but they clearly wanted to kill off the embarrassment Jobs created back when he was still learning what happens when you consider formal-training/experience to be a handicap.
Every piece of code has maintenance and security concerns. The last thing you want is an old security vulnerability showing up because of a bug in QuickDraw GX, OpenDoc and the Publish and Subscribe system
A modern low end iPad -the 10.2 inch $329 iPad has 3GB of RAM, no swap and a lower end processor than most modern laptops, yet it runs faster than low end Surface laptops with more RAM and faster processors and has longer battery life. Windows and Intel are albatrosses for mobile devices.
As far as what MS “learned”, Microsoft completely missed mobile and every other trend in the last 20 years because they were concerned with backwards compatibility.
Seeing where Apple was when Jobs came back and where they are now and comparing them to MS in terms of revenue and profit, can you really say that Apple made a bad decision?
On the other hand, where are all of the Apple’s former competitors in the PC market now?
As far as “formal training”, how did that help MS during the Ballmer era? Or heck how did it help Apple during the Sculley/Amelio era?