
The Catch-22 of Building a Business on Apple’s APIs - tambourine_man
https://blog.astropad.com/the-catch-22-of-apple-apis/
======
Slartie
How is this a catch-22 situation?

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 ;-)

~~~
jjeaff
I suppose it is a catch 22 because there are plenty of apps/businesses out
there that would not be able to exist were it not for the apple ecosystem.

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.

~~~
close04
> there are plenty of apps/businesses out there that would not be able to
> exist were it not for the apple ecosystem

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.

[0]
[https://en.wikipedia.org/wiki/Catch-22_(logic)](https://en.wikipedia.org/wiki/Catch-22_\(logic\))

~~~
basch
The phrase they were looking for was faustian bargain, although even then,
Apple's APIs are not all or nothing (but if you use some, maybe just use them
all cuz youre stuck either way?)

------
musicale
Using an iPad as a Cintiq-like touchscreen for macOS is a feature that I've
wanted for years as something that should "just work" out of the box as a
built-in feature. I've been greatly dissatisfied with third-party solutions
and their annoying drawbacks such as subscription pricing (AstroPad, Duet),
hardware dongles (Luna), and a generally poor user experience (all of them.)

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.

~~~
duskwuff
> the old Target Display mode which was unfortunately dropped from the iMac 5K

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.

~~~
month13
Had Target Display mode still been a thing i'm sure many would've bought a 5k
iMac to use only as a dumb display.

~~~
emsy
People downvoting this probably don’t know how hard 5k displays were to come
by in the past (and still are occasionally).

~~~
scarface74
And still only one reputable company sells them - LG. Dell and HP got out of
the market.

------
scarface74
I am so sick of their whining. What they “created” - a method of using the
iPad as a second display - was done by an app that was introduced in 2010 less
than 3 months after the iPad was introduced.

[https://www.cnet.com/news/turn-your-ipad-into-a-second-
monit...](https://www.cnet.com/news/turn-your-ipad-into-a-second-monitor/)

------
yannikyeo
The article mentioned adopting Swift for core algo would tie you into Apple
eco, as Swift is not "cross-platform". Swift however is open source and cross
platform, just not well supported in other platform. Wondering if adopting
Flutter and Dart will end you up in the same boat? Well Flutter is cross
platform, but that cross platform support is dependent on how Google wants to
support it. You cant just port it into let say a new watch platform or
Raspberry Pi or Huawei's HongMengOS. Maybe the best route, as in the article,
is to use a really cross platform languages C, C++, Rust for product core, and
then layer it with the native UI code. Anyone has any idea if this is how
Adobe develop their products?

~~~
mpiedrav
According to Stroustrup[1], Adobe builds everything in C++. Perhaps they add
some C# shim for Windows and Objective-C (or even Swift) for Mac.

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.

[1]
[http://www.stroustrup.com/applications.html](http://www.stroustrup.com/applications.html)

[2] [https://isocpp.org/about](https://isocpp.org/about)

~~~
evilduck
Adobe is also old, as software vendors go. I have no knowledge of their
internal workings but it wouldn't surprise me if they still have some code in
a product that predates the existence of C# or Apple's adoption of Objective
C. They also have a need for algorithmic speed, and C++ has long been a prime
tool for that.

------
Gorbzel
While the article makes some good points, it conflates the variety of distinct
components that comprise a truly sherlock-proof product/application/codebase.

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.

~~~
musicale
I agree that having the core application logic be cross-platform but
customizing the app with first-class native support for each platform usually
yields a superior user experience, particularly for desktop and productivity
applications; even other software such as utilities or development tools can
become more pleasant and useful if they are delivered with a first-class
platform-native interface as well as well-integrated native functionality.

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.

------
musicale
> A subscription iOS app that doesn’t have it’s own subscription backend
> server

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.

~~~
alluro2
If it "simply" allows you a feature that you want and that did not exist
otherwise - and there doesn't seem to be anything remotely simple about it
(wireless, low-latency, filtering the input noise, etc) - it seems only normal
to pay for it...A one-time fee would be nicer, for sure, as I'm sure AstroPad
wouldn't mind - but if you're battling API changes with every OS revision, and
trying to provide a product that Apple can cripple any day (like they did with
Sidecar), you're primarily forced to go subscription route by Apple to ensure
survival...

~~~
taneq
I think the problem here is that software should not be "as a service". Once a
platform starts down the "evergreen" route they stop caring about breaking
backward compatibility and then everyone else has to churn along with them. It
creates a huge amount of busywork for everyone.

~~~
scarface74
So should Apple have kept the silicon required to support 32 bit apps in their
ARM chips forever?

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”.

~~~
wolfgke
> So should Apple have kept the silicon required to support 32 bit apps in
> their ARM chips forever?

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.

~~~
scarface74
_Yes. That is why x86 became so successful and why Windows is so much loved by
big corporations._

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.

~~~
vaxman
How did you get that Intel and Microsoft failed in mobile "markets" because
they had backwards compatibility with 32-bit and 16-bit apps? (I'm thinking
you might not know the difference between RISC and CISC --hint: one is not
better. than the other.)

> 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.

~~~
scarface74
_How did you get that Intel and Microsoft failed in mobile "markets" because
they had backwards compatibility with 32-bit and 16-bit apps? (I'm thinking
you might not know the difference between RISC and CISC --hint: one is not
better. than the other.)_

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.

------
taikahessu
A good reminder. It holds true with any vendor.

