6 ms·

The Catch-22 of Building a Business on Apple’s APIs

yannikyeo 7y ago
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 7y ago
  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
  - pjmlp 7y ago
    Plus it is available of the box across all major OS SDKs, so no need for extra tooling, or libraries, beyond what those SDKs already offer.
  - evilduck 7y ago
    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.
- oarsinsync 7y ago
  > 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 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.
Gorbzel 7y ago
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 7y ago
  Selling third-party OS extensions is a risky bet over time: Apple tends to remove and/or lock down OS extension mechanisms over time for security reasons, and also aggressively revises and deprecates many of its APIs every year; and if an OS extension fixes an obvious omission or is simply a great idea that Apple hasn't implemented yet, there's always the chance that Apple will add the feature to the baseline OS itself.
- musicale 7y ago
  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 7y ago
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 7y ago
  > 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 7y ago
    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 7y ago
      People downvoting this probably don’t know how hard 5k displays were to come by in the past (and still are occasionally).
      - scarface74 7y ago
        And still only one reputable company sells them - LG. Dell and HP got out of the market.
musicale 7y ago
> 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 7y ago
  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 7y ago
    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 7y ago
      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 7y ago
        > 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.
Slartie 7y ago
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 7y ago
  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 7y ago
    > 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 7y ago
      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?)
scarface74 7y ago
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-monitor/ https://www.cnet.com/news/turn-your-ipad-into-a-second-monit...
taikahessu 7y ago
A good reminder. It holds true with any vendor.

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 7y ago
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
- pjmlp 7y ago
  Plus it is available of the box across all major OS SDKs, so no need for extra tooling, or libraries, beyond what those SDKs already offer.
- evilduck 7y ago
  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.
oarsinsync 7y ago
> 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 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.

Gorbzel 7y ago

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 7y ago
Selling third-party OS extensions is a risky bet over time: Apple tends to remove and/or lock down OS extension mechanisms over time for security reasons, and also aggressively revises and deprecates many of its APIs every year; and if an OS extension fixes an obvious omission or is simply a great idea that Apple hasn't implemented yet, there's always the chance that Apple will add the feature to the baseline OS itself.
musicale 7y ago
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 7y ago

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 7y ago
> 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 7y ago
  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 7y ago
    People downvoting this probably don’t know how hard 5k displays were to come by in the past (and still are occasionally).
    - scarface74 7y ago
      And still only one reputable company sells them - LG. Dell and HP got out of the market.

musicale 7y ago

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

Slartie 7y ago

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 7y ago
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 7y ago
  > 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 7y ago
    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?)

scarface74 7y ago

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-monitor/ https://www.cnet.com/news/turn-your-ipad-into-a-second-monit...

taikahessu 7y ago

A good reminder. It holds true with any vendor.