SwiftUI and Catalyst: Apple executes its invisible transition strategy(macworld.com)
macworld.com
SwiftUI and Catalyst: Apple executes its invisible transition strategy
https://www.macworld.com/article/3402057/swiftui-and-catalyst-apple-executes-its-invisible-transition-strategy.html
5 comments
I would say the invisible strategy here is to move away and ultimately deprecate AppKit because it carries decades of legacy compatibility and is limited by being bound to Objective C, while clearly Apples vision is that the future is Swift.
Carbon.
Has been deprecated since 10.8 (2012) and was never ported to 64 Bit. It was pretty clear they weren't working on a Carbon replacement imo.
True, but the official deprecation was quite sudden, and anyone using at the time and who expected Apple to be open and sensible about their API direction was caught quite off guard.
I largely agree, although disagree about the point that this is unique to Apple.
I think Microsoft also does quite a good job of maintaining compatibility and slowly bringing people forward (to the point where it's often used as a negative argument). As an outsider, the whole UWP thing felt like a bit of a mess, so I'm not even sure what's the "modern" way anymore to build Windows apps – is it UWP? WinForms? something else?
Apple benefits from having higher average quality of developers in its ecosystem, which allows them to sunset things faster than, say someone like Microsoft, who has to keep things backwards compatible for a decade+. While there are larger applications (Adobe Suite) that dragged their heels on the move from Carbon to Cocoa, a lot of software on macOS/iOS is written by independent developers who do tend more to keep up with the latest frameworks.
I think Microsoft also does quite a good job of maintaining compatibility and slowly bringing people forward (to the point where it's often used as a negative argument). As an outsider, the whole UWP thing felt like a bit of a mess, so I'm not even sure what's the "modern" way anymore to build Windows apps – is it UWP? WinForms? something else?
Apple benefits from having higher average quality of developers in its ecosystem, which allows them to sunset things faster than, say someone like Microsoft, who has to keep things backwards compatible for a decade+. While there are larger applications (Adobe Suite) that dragged their heels on the move from Carbon to Cocoa, a lot of software on macOS/iOS is written by independent developers who do tend more to keep up with the latest frameworks.
Apple benefits from not being in "Enterprise".
Enterprise is where you have average developers with mediocre managers and ill-formed specifications working to inadequate (but overrunning) budgets. Something gets nailed together to support the business, and once it's working you're never allowed to touch it again. The king of this kind of line-of-business app used to be VB6. There was a brief phase were people wrote intranet applications with embedded ActiveX controls and got permanently stuck on IE6. These days it's more likely to involve SAP or Sharepoint.
These customers made Microsoft a lot of money from all those desktops and Windows Server client access licenses, but they're extremely conservative.
And maybe they have a point; I can see what the advantage of UWP is for Microsoft, but as a developer it's not a clear win over WinForms.
Enterprise is where you have average developers with mediocre managers and ill-formed specifications working to inadequate (but overrunning) budgets. Something gets nailed together to support the business, and once it's working you're never allowed to touch it again. The king of this kind of line-of-business app used to be VB6. There was a brief phase were people wrote intranet applications with embedded ActiveX controls and got permanently stuck on IE6. These days it's more likely to involve SAP or Sharepoint.
These customers made Microsoft a lot of money from all those desktops and Windows Server client access licenses, but they're extremely conservative.
And maybe they have a point; I can see what the advantage of UWP is for Microsoft, but as a developer it's not a clear win over WinForms.
Seriously. The true geniuses are the non enterprise startup developers developing in JavaScript.
Wait what...
Edit: There’s nothing wrong with being a JS developer. Heck, my main job is JS. My point is the choice of language hardly determines what kind of developer you are. I’ve seen great developers working on VBA and I’ve seen shitty developers working on C/C++ and Java.
To play devils advocate, I don’t think there are too many terrible developers working on Haskell and Rust though. Yet.
Wait what...
Edit: There’s nothing wrong with being a JS developer. Heck, my main job is JS. My point is the choice of language hardly determines what kind of developer you are. I’ve seen great developers working on VBA and I’ve seen shitty developers working on C/C++ and Java.
To play devils advocate, I don’t think there are too many terrible developers working on Haskell and Rust though. Yet.
I think he's saying the devs are average because they're in massive corps that hire average devs, who are managed by nontechnical, average middle managers.
Those corps often like Microsoft, so that's what those devs work in.
He's not saying working in Microsoft technologies = not a good dev.
Those corps often like Microsoft, so that's what those devs work in.
He's not saying working in Microsoft technologies = not a good dev.
There's a joke about monoids and semigroups in here somewhere but my lack of a college education is hindering me.
Someone has to be "average" by sheer laws of statistics. It's not really a criticism.
Most people are average. As defined by the bell curve
> The king of this kind of line-of-business app used to be VB6.
You say that like it's not still happening... VB6 is still the go-to tool at a certain blue cross and blue shield franchise - and probably at many others around the country. They post jobs(active postings right now) for .NET developers with VB6 experience. They do it under the guise to "help port existing applications", but in reality they are still developing new features with it, and will likely never stop.
You say that like it's not still happening... VB6 is still the go-to tool at a certain blue cross and blue shield franchise - and probably at many others around the country. They post jobs(active postings right now) for .NET developers with VB6 experience. They do it under the guise to "help port existing applications", but in reality they are still developing new features with it, and will likely never stop.
And even now, there are few tools where it's easier to make complex LOB CRUD UIs than in VB6.
If by easier you refer to the whole lifecycle of a reasonably secure application, I’m sure that many web frameworks with rapid CRUD builders are much easier, and don’t require distributing binaries, standardizing the desktop platform to Windows, or giving the client binary direct access to a SQL server.
Why not move to VB.NET? I thought the whole point of VB.NET was to give heavy enterprise VB6 developers an obvious non-legacy transition path that doesn’t require any retooling, and only a little (mostly automatic) refactoring.
VB.NET has only superficial similarity with VB6. If you move from VB6 to VB.NET you have to rewrite the whole thing so you may as well go to C#.
that's the problem with the .NET front-end tools in general. They have no transition path to their previous version. VB6 to VB.NET is hard. WinForms to WPF is hard. WPF to UWP is a little better but still hard. Yes, they all still run but moving your project to the new shiny tech is very hard.
that's the problem with the .NET front-end tools in general. They have no transition path to their previous version. VB6 to VB.NET is hard. WinForms to WPF is hard. WPF to UWP is a little better but still hard. Yes, they all still run but moving your project to the new shiny tech is very hard.
> you move from VB6 to VB.NET you have to rewrite the whole thing so you may as well go to C#.
Since C# and VB.NET are essentially equivalent in capability, if you are a programmer with no .NET experience and a background in VB6 but not C/C++/Java, looking to rewrite an existing VB6 codebase for .NET, why would you go to hassle of additional unfamiliar syntax to go to C#?
> that's the problem with the .NET front-end tools in general. They have no transition path to their previous version. VB6 to VB.NET is hard.
VB6 to VB.NET is not a successive version of a .NET tool, front-end or otherwise.
Since C# and VB.NET are essentially equivalent in capability, if you are a programmer with no .NET experience and a background in VB6 but not C/C++/Java, looking to rewrite an existing VB6 codebase for .NET, why would you go to hassle of additional unfamiliar syntax to go to C#?
> that's the problem with the .NET front-end tools in general. They have no transition path to their previous version. VB6 to VB.NET is hard.
VB6 to VB.NET is not a successive version of a .NET tool, front-end or otherwise.
"if you are a programmer with no .NET experience and a background in VB6 but not C/C++/Java, looking to rewrite an existing VB6 codebase for .NET, why would you go to hassle of additional unfamiliar syntax to go to C#?"
That sounds obvious. Yet, the group I was in using VB6 thought VB.NET and what people were doing with it looked like it was going to be a bigger learning experience that wasn't just VB6 on a new VM. More like we would be learning a new language, libraries, and so on. So, some of us learned a new language, libraries, and so on with some extra benefits over another BASIC.
C, C++, Java, and C# are where everyone went among those I knew. Some of us kept using stuff with VB6, clones, and/or homebrew 4GL's that were BASIC-like. Most folks just put all that time and effort they perceived as necessary into a language that was a step up. Especially, career-wise.
That sounds obvious. Yet, the group I was in using VB6 thought VB.NET and what people were doing with it looked like it was going to be a bigger learning experience that wasn't just VB6 on a new VM. More like we would be learning a new language, libraries, and so on. So, some of us learned a new language, libraries, and so on with some extra benefits over another BASIC.
C, C++, Java, and C# are where everyone went among those I knew. Some of us kept using stuff with VB6, clones, and/or homebrew 4GL's that were BASIC-like. Most folks just put all that time and effort they perceived as necessary into a language that was a step up. Especially, career-wise.
"VB6 to VB.NET is not a successive version of a .NET tool, front-end or otherwise."
Correct. But VB6 was the main tool for quick UI development before Winforms took that place. Things that would have been written with VB6 would be written in Winforms once it came out.
Correct. But VB6 was the main tool for quick UI development before Winforms took that place. Things that would have been written with VB6 would be written in Winforms once it came out.
Because VB.NET is like VB(5|6) in name alone. If an enterprise is going to move to .NET they might as well move to c#.
I really don't know - I was never in that section of the business. Speculating...maybe they have their framework or some other VB6 piece certified for HIPPA compliance and don't want to change?
That industry is very old fashioned though - another good example is that every blue cross franchise uses the same software to process medicare/medicaid claims, and that software is powered by COBOL. At first it's shocking and you wonder how on earth things stay on the rails...but after a while you get used to it, a strange status quo.
That industry is very old fashioned though - another good example is that every blue cross franchise uses the same software to process medicare/medicaid claims, and that software is powered by COBOL. At first it's shocking and you wonder how on earth things stay on the rails...but after a while you get used to it, a strange status quo.
I feel like it makes sense to use COBOL to talk to a government mainframe that’s likely also using COBOL, and likely has a wire protocol specced as a set of ready-to-use COBOL client structs.
Sort of like, in the modern day, it makes sense to use Go if the goal is to write an adapter that takes stuff from your database and pushes it out to some remote consumer that speaks ProtoBuf, and has a ready-to-use ProtoBuf schema.
Sort of like, in the modern day, it makes sense to use Go if the goal is to write an adapter that takes stuff from your database and pushes it out to some remote consumer that speaks ProtoBuf, and has a ready-to-use ProtoBuf schema.
Microsoft botched VB.NET so completely that there is no path forward. VB.NET was derisively called Visual Fred by VB6 developers because it's essentially a different language that should have a different name.
http://vb.mvps.org/vfred/breaks.asp
It would have been entirely possible to make a CLR version of VB that was 99% compatible with VB6 -- and that's what they should have done. It would have given a clear upgrade path for a huge number of applications. Instead they just re-skinned C#.
http://vb.mvps.org/vfred/breaks.asp
It would have been entirely possible to make a CLR version of VB that was 99% compatible with VB6 -- and that's what they should have done. It would have given a clear upgrade path for a huge number of applications. Instead they just re-skinned C#.
VB.NET was 99% compatible with the good parts of VB6. The problem was and remains that every project ever actually written in VB6 was written with at least some of the worst parts of VB6 in use. That list of "breaks" is a lovely list of some of the horrors that probably shouldn't have existed in VB to begin with.
> VB.NET was 99% compatible with the good parts of VB6.
Without backwards compatibility with VB6, there are no good parts of VB.NET. The Visual Basic syntax isn't that great to begin with and VB.NET then added more horrible keywords like `AndAlso` and `OrElse`.
In my opinion, most of that list isn't actually too bad. But it doesn't matter, all the horrors should have been included and then deprecated, giving a smooth upgrade path. Instead all VB6 code had to stay on VB6 as it was no where near 99% compatible. You have a language with different semantics, completely new way of building the UI, and superficial but incomplete syntax similarities. Anyone who was forced to rewrite, and was smart, went to C#.
Without backwards compatibility with VB6, there are no good parts of VB.NET. The Visual Basic syntax isn't that great to begin with and VB.NET then added more horrible keywords like `AndAlso` and `OrElse`.
In my opinion, most of that list isn't actually too bad. But it doesn't matter, all the horrors should have been included and then deprecated, giving a smooth upgrade path. Instead all VB6 code had to stay on VB6 as it was no where near 99% compatible. You have a language with different semantics, completely new way of building the UI, and superficial but incomplete syntax similarities. Anyone who was forced to rewrite, and was smart, went to C#.
Sure there is, I have done quite a lot work in life sciences enterprises where VB.NET rules, not R nor Python as many HNers would like to talk about.
Heavy Office users that have outgrown VBA and turn to VB.NET to keep doing their little department apps for data analysis without additional help from IT other than getting Visual Studio on their systems.
Also VB.NET gets all the tooling that C++ and C# get, not like the black swan in .NET, F#.
Heavy Office users that have outgrown VBA and turn to VB.NET to keep doing their little department apps for data analysis without additional help from IT other than getting Visual Studio on their systems.
Also VB.NET gets all the tooling that C++ and C# get, not like the black swan in .NET, F#.
I know life sciences and I know enterprise
What’s an example of life sciences enterprises
What’s an example of life sciences enterprises
Life sciences that are part of Fortune 500.
Several examples to pick from.
Several examples to pick from.
Agreed that VB.NET is essentially C# in VB6ish syntax to largely accommadate legacy Windows developers
> ill-formed specifications working to inadequate (but overrunning) budgets. Something gets nailed together to support the business, and once it's working you're never allowed to touch it again.
That sounds like a small startup, too.
(I won't speak to the "average developers" and "mediocre managers" bit, though I assure you they're not unique to big enterprises.)
That sounds like a small startup, too.
(I won't speak to the "average developers" and "mediocre managers" bit, though I assure you they're not unique to big enterprises.)
Although I have to say, VB6 was AWESOME in the late 90s. :)
The same argument goes to Objective-C in the 80s :)
I still find writing Objective-C relatively enjoyable in this decade. It’s much nicer than C++, for example.
And COBOL in the 60s. :-D
VB6 was my first programming language and it was indeed awesome to open my eyes.
There are still no desktop rapid UI dev tools on par with VB6.
There are no rapid UI dev tools anywhere that hold a candle to VB6. Winforms comes the closest. Web development is just a disaster area; I've tried a few things like Bootstrap Studio that try to get something like the ease of slapping together a UI with a visual designer that we used to have, but it is not even close; wiring up events is still laborious because of client-server and data binding, and CSS makes a mockery of attempts to have a WYSIWYG editor. Razor Pages looked like it might have been trending in that direction, but I am unclear whether that is still being worked on.
So I'm hacking away in a text editor, running a babel/webpack compile and bundle process that makes my Visual Studio solution builds seem instantaneous, firing up the app, hard-reloading the page a few times to make sure nothing is cached, then realizing I fucked something up or made a typo, and starting over. It's stupidly laborious and time-consuming. This is not progress.
So I'm hacking away in a text editor, running a babel/webpack compile and bundle process that makes my Visual Studio solution builds seem instantaneous, firing up the app, hard-reloading the page a few times to make sure nothing is cached, then realizing I fucked something up or made a typo, and starting over. It's stupidly laborious and time-consuming. This is not progress.
That's true only for web development. Due to nature of web development is next to imposible to have a good RAD tool that can cover all use cases.
For desktop and mobile there are a few RAD tools. Some of them: QT Creator, Windows Forms, Delphi, C++ Builder X, Mono.
Maybe some are not of the highest quality and maybe there's not enough RAD tools, but that's because many people think that "true" development happens only in VI and command line.
As someone already commented, a good RAD tool can save 90% percent of the time because you don't have to connect by hand signals, events with handlers and you don't have to draw the UI by code, unless you need something specific. Doing this tasks is a tedious and boring work, takes time that is better spent doing something else like working on the app logic.
For desktop and mobile there are a few RAD tools. Some of them: QT Creator, Windows Forms, Delphi, C++ Builder X, Mono.
Maybe some are not of the highest quality and maybe there's not enough RAD tools, but that's because many people think that "true" development happens only in VI and command line.
As someone already commented, a good RAD tool can save 90% percent of the time because you don't have to connect by hand signals, events with handlers and you don't have to draw the UI by code, unless you need something specific. Doing this tasks is a tedious and boring work, takes time that is better spent doing something else like working on the app logic.
There is a VB6-like tool for the web! I know, because I co-founded it: https://anvil.works
I have ranted at length before on the reason that the Web is not amenable to RAD tooling. The short answer is that you have five different programming languages (HTML+JS+CSS+Python+SQL), with each component generating source code in another language, and that's impossible for a single development tool to manage sensibly.
To take one example: One of the best things about VB6 was autocomplete. But there's no sensible way to autocomplete what keys are in a JSON value that's been generated by a REST endpoint written in Python serving data from generated SQL, all with about 4-5 different frameworks in the way.
So for Anvil, we dispensed with that and did everything in one language (Python). Python on the front end, Python on the back-end, a Python-native database, a drag-and-drop designer producing UI components that are Python objects...and all of a sudden, it's all one representation and you can autocomplete it!
(I gave a talk about how the autocompleter works at PyCon UK a couple of years back: https://anvil.works/blog/python-autocompleter-pycon17)
I have ranted at length before on the reason that the Web is not amenable to RAD tooling. The short answer is that you have five different programming languages (HTML+JS+CSS+Python+SQL), with each component generating source code in another language, and that's impossible for a single development tool to manage sensibly.
To take one example: One of the best things about VB6 was autocomplete. But there's no sensible way to autocomplete what keys are in a JSON value that's been generated by a REST endpoint written in Python serving data from generated SQL, all with about 4-5 different frameworks in the way.
So for Anvil, we dispensed with that and did everything in one language (Python). Python on the front end, Python on the back-end, a Python-native database, a drag-and-drop designer producing UI components that are Python objects...and all of a sudden, it's all one representation and you can autocomplete it!
(I gave a talk about how the autocompleter works at PyCon UK a couple of years back: https://anvil.works/blog/python-autocompleter-pycon17)
I place a lot of the blame for this stagnation followed by backward progress on the fact that a decent number of developers actually have a kind of quiet or even subconscious contempt for ease of use and RAD tools. "Real men" code by hand in a text editor. RAD tools are for wimps. As a result few developers work on them or use them.
It's sad because what developers are really doing here is wasting tons and tons of time. If we had really awesome modern and especially cross platform RAD tools the time savings would be enormous. We could spend that time working on more interesting stuff than wiring up controls to events.
It's sad because what developers are really doing here is wasting tons and tons of time. If we had really awesome modern and especially cross platform RAD tools the time savings would be enormous. We could spend that time working on more interesting stuff than wiring up controls to events.
I absolutely agree on you, the entry level of Windows developer used to be lower than other developers. People use visual studio to drag and drop the controls, glue the code all together. You don’t need to type command, you don’t need to understand how the things work behind.
This may be ok for a junior position, and in closed environment. However, people are lazy and not all people are hard core. As a result, there are a lot .NET senior who don’t actually “know” how to code. Nowadays things become extremely complicated, all sort of API, library and framework. Even Microsoft can’t provide a completed solution, and it go back to command line approach with .NET core. I have been recently contacted by my ex-employee who want me to do some C# API communication freelance because their .NET developers just don’t know how to read the documentation and implement them in code.
This may be ok for a junior position, and in closed environment. However, people are lazy and not all people are hard core. As a result, there are a lot .NET senior who don’t actually “know” how to code. Nowadays things become extremely complicated, all sort of API, library and framework. Even Microsoft can’t provide a completed solution, and it go back to command line approach with .NET core. I have been recently contacted by my ex-employee who want me to do some C# API communication freelance because their .NET developers just don’t know how to read the documentation and implement them in code.
> as a developer it’s not a clear win over WinForms
Can you put a WinForms app into the Microsoft Store? UWP apps having a marketplace to sell them is kind of a point in their favour, even if it’s an entirely-artificial restriction Microsoft made up to push UWP.
Can you put a WinForms app into the Microsoft Store? UWP apps having a marketplace to sell them is kind of a point in their favour, even if it’s an entirely-artificial restriction Microsoft made up to push UWP.
Is the Windows Store a thing that people actually use? I'm broken by decades of Windows use, going back to 3.1 at this point, so I am completely conditioned to installing software off of disks (it's still a thing, I swear!) or downloading from a website. I also run Windows 10 LTSB on all my machines, so there is no Store available there.
The vast majority of the paid software I have consists of games that come from Steam or Gog. Steam really doesn't work well with UWP games, and the Gog stuff I have is mostly nicely packaged DosBox games from an earlier age.
The vast majority of the paid software I have consists of games that come from Steam or Gog. Steam really doesn't work well with UWP games, and the Gog stuff I have is mostly nicely packaged DosBox games from an earlier age.
99% of users don’t have optical drives anymore so installing software from disks isn’t really that much of a thing anymore. You have to provide a usb optical drive with the disk if you want that and then you might as well provide a thumb drive.
I’m mostly a Mac user, but when setting up a friend’s Windows 10 PC, I used the Windows Store to download whatever apps I could that were available there, and only installed from the web for apps that didn’t have Windows Store versions.
My thinking is:
1. apps on the Windows Store have some level of sandboxing forced upon them, so I can rest assured that the Windows Store releases of these apps won’t make a mess of their computer, even after major-version updates. (Remember uTorrent?)
2. Windows Store apps get automatically updated in the background without ever running them—like apps installed via the OS package manager on Linux. Give some people any chance to cancel/delay an update, and they’ll do it, indefinitely. Better for most regular users [who aren’t relying on any reflexive professional workflows] to have their apps just “be” the newest version, at all times.
My thinking is:
1. apps on the Windows Store have some level of sandboxing forced upon them, so I can rest assured that the Windows Store releases of these apps won’t make a mess of their computer, even after major-version updates. (Remember uTorrent?)
2. Windows Store apps get automatically updated in the background without ever running them—like apps installed via the OS package manager on Linux. Give some people any chance to cancel/delay an update, and they’ll do it, indefinitely. Better for most regular users [who aren’t relying on any reflexive professional workflows] to have their apps just “be” the newest version, at all times.
The sandboxing part isn't quite true anymore. You can use Desktop Bridge to package win32 apps for the store. These apps are not sandboxed in the way that UWP apps are though they are still kinda-sorta sandboxed (they can access any file the user can, but the appdata folder and registry edits are sandboxed).
There is also some sort of vaguely-stated plan to allow totally unsandboxed win32 apps in the store at some point in the future but seems to specifically only apply to games.
https://docs.microsoft.com/en-us/windows/msix/desktop/deskto...
There is also some sort of vaguely-stated plan to allow totally unsandboxed win32 apps in the store at some point in the future but seems to specifically only apply to games.
https://docs.microsoft.com/en-us/windows/msix/desktop/deskto...
It is, most of the new software I get is via the store.
I believe that restriction has been lifted:
https://www.theverge.com/2019/5/30/18645609/microsofts-unive...
https://www.theverge.com/2019/5/30/18645609/microsofts-unive...
Yes, since two years now.
Having been through the whole .Net Framework -> .Net Core processs, I think one of the biggest problems with MS is that they just have pathetic naming.
Apple creates these new names that are unique, exciting, and evoke something concrete. It makes it easier to remember what they mean when they’re talking about something. So for example, their new UI framework is called SwiftUI which builds off the swift legacy and logo and the emotion of being faster therefore better, whereas MS’s was UWP. WTF is UWP supposed to evoke. How am I supposed to mentally associate that with something.
And the .Net stuff was otherworldly. You had .Net Core, .Net framework, and .Net standard. Other than Core, neither of the other have any unique meanings. All the 3 are frameworks and standards. Or strongly associated with frameworks and standards. 2 of them are technologies, and one is just a document, but they all sound the same.
.Net core sounds like it should be a subset of the other stuff, yet it’s the future. If it wasn’t MS who invented .Net Core, they may have given it a different name, say, I don’t know, Mono, and it wouldn’t confuse the crap out of people. They would need to be told it’s a ground up rewritten open source implementation of the .Net Framework which will eventually supersede it once and they would not get confused again.
Apple creates these new names that are unique, exciting, and evoke something concrete. It makes it easier to remember what they mean when they’re talking about something. So for example, their new UI framework is called SwiftUI which builds off the swift legacy and logo and the emotion of being faster therefore better, whereas MS’s was UWP. WTF is UWP supposed to evoke. How am I supposed to mentally associate that with something.
And the .Net stuff was otherworldly. You had .Net Core, .Net framework, and .Net standard. Other than Core, neither of the other have any unique meanings. All the 3 are frameworks and standards. Or strongly associated with frameworks and standards. 2 of them are technologies, and one is just a document, but they all sound the same.
.Net core sounds like it should be a subset of the other stuff, yet it’s the future. If it wasn’t MS who invented .Net Core, they may have given it a different name, say, I don’t know, Mono, and it wouldn’t confuse the crap out of people. They would need to be told it’s a ground up rewritten open source implementation of the .Net Framework which will eventually supersede it once and they would not get confused again.
> Apple creates these new names that are unique, exciting, and evoke something concrete. It makes it easier to remember what they mean when they’re talking about something.
There is a thought here: when something is well designed (including branding), it's possibly attributable to a better process used to create the product as a whole (in this case the frameworks and API).
I've worked at places where acronyms are rife, and they're usually places that didn't feel the product needed to be sold (possibly because they didn't think they had any competition).
Other places I've worked where we actually pitched/sold the product (either internally or externally) resulted in a lot more overall thought about what the product did and how the customer would use it and consequently the naming.
There is a thought here: when something is well designed (including branding), it's possibly attributable to a better process used to create the product as a whole (in this case the frameworks and API).
I've worked at places where acronyms are rife, and they're usually places that didn't feel the product needed to be sold (possibly because they didn't think they had any competition).
Other places I've worked where we actually pitched/sold the product (either internally or externally) resulted in a lot more overall thought about what the product did and how the customer would use it and consequently the naming.
Oh my god yes Microsoft’s naming conventions are mind boggling.
.Net Standard, .Net Framework, .Net Core, and they all do slightly different things, and they seemingly change with version, and now there’s .Net Framework 5, which apparently replaces/unifies some of them but it’s not super clear. Then you’ve got C# and F# and the specific language versions of those. Oh also, don’t forget the fact that there’s inexplicably like, 3 different package managers, which may or may not pull from the same place and it’s not clear what the differences are.
Coming from Python (and a little bit of Rust) I had literally no idea what was going on. I tried to learn C# twice and gave up out of sheer irritation and confusion.
.Net Standard, .Net Framework, .Net Core, and they all do slightly different things, and they seemingly change with version, and now there’s .Net Framework 5, which apparently replaces/unifies some of them but it’s not super clear. Then you’ve got C# and F# and the specific language versions of those. Oh also, don’t forget the fact that there’s inexplicably like, 3 different package managers, which may or may not pull from the same place and it’s not clear what the differences are.
Coming from Python (and a little bit of Rust) I had literally no idea what was going on. I tried to learn C# twice and gave up out of sheer irritation and confusion.
Is there a third package manager now? There's the blessed one, NuGet, which most use, and Paket, which the cool kids and F# people use, but if there's another one out there I'm drawing a blank.
You can use the CLI as to do stuff. Not sure if it counts as package manager, but coming from Python, being faced with 3 different ways to install packages (I'm still not sure how environments/projects are supposed to work in .Net) certainly added to the confusion.
Oh god yes. It's absurdly confusing. Not to mention "Windows 10 IoT Enterprise" versus "Windows 10 IoT" - the former is minified real x86 Windows, the latter is the CE successor and runs on the Raspberry Pi.
Branding is far more important for dev tools than many realize. They’re just as much of a product as iPhones and Surfaces are but this has yet to register with the eng teams of a lot of companies.
Agreed...and with the luck of Microsoft in this department the one awesomely named product of the last 15 years -- Silverlight -- was doomed because it was too cool for Redmond.
(That and Turtleneck Steve prohibited browser plugins on iOS.)
(That and Turtleneck Steve prohibited browser plugins on iOS.)
Well it only took 10 years for the others to catch up to that idea so perhaps ‘Turtleneck Steve’ was right all along.
The tech survived, the brand didn't. I wonder sometimes if the Windows Mobile team was correct and UWP should have just kept the Silverlight brand name even as the underlying tech shifted so much, because the outer XAML shell is still so similar at the end of the day.
Why was Silverlight so cool sounding? For me it's not a meaningful or evocative name.
A good brand name doesn't require explanation.
A good brand name doesn't require explanation.
> So for example, their new UI framework is called SwiftUI which builds off the swift legacy and logo and the emotion of being faster therefore better
I mean the pun is obvious, but a swift is a kind of bird.
I specifically think it's a bad idea to name things "fast", because history will catch up to you and it might not be fast anymore, or it might be unsafe - and then what will you call the next thing?
Actually, this happened in Swift. -Ounchecked (no bounds checks) was originally "-Ofast", but thankfully they changed it.
I mean the pun is obvious, but a swift is a kind of bird.
I specifically think it's a bad idea to name things "fast", because history will catch up to you and it might not be fast anymore, or it might be unsafe - and then what will you call the next thing?
Actually, this happened in Swift. -Ounchecked (no bounds checks) was originally "-Ofast", but thankfully they changed it.
I will counter argue the imputation of misnaming with the auto industry examples that the Japanese cars with catchy and sexy names such as Toyota Camry, Honda Clarity, Nissan Rogue; whereas the German counterpart with unimaginative M-Benz c300, e550; BMW i300, i3, i8... and yet German cars sales remain strong
But the German numbering system is a brand. You know that a 3-series BMW will get your a certain size, an M-class is high performance, etc.
The predictable numbers are as important to the brand as the manufacturer name.
The predictable numbers are as important to the brand as the manufacturer name.
I don't see how SwiftUI/SUI is any different from UWP?
I guess beauty is in the eye of the beholder.
I do agree though with the .NET stuff - I have been out of the ecosystem for a while and have no idea what is going on any more.
I guess beauty is in the eye of the beholder.
I do agree though with the .NET stuff - I have been out of the ecosystem for a while and have no idea what is going on any more.
Well nobody other than yourself is calling it SUI.
And UWP stands for Universal Windows Platform which is hopelessly generic.
And UWP stands for Universal Windows Platform which is hopelessly generic.
> I'm not even sure what's the "modern" way anymore to build Windows apps – is it UWP? WinForms? something else?
I feel like Microsoft has made this intentionally obscure because their business model requires that they talk out of both sides of their mouth: they want enterprises building their line-of-business CRUD apps to feel confident and secure in using older APIs like WinForms, by telling them that they’re using first-class APIs that will be supported in the long term, and aren’t being deprecated just because there are other, newer APIs; and, at the same time, they want developers coming into the ecosystem fresh to find UWP first, so that UWP apps get built and make Windows tablet usage easier/better.
I feel like Microsoft has made this intentionally obscure because their business model requires that they talk out of both sides of their mouth: they want enterprises building their line-of-business CRUD apps to feel confident and secure in using older APIs like WinForms, by telling them that they’re using first-class APIs that will be supported in the long term, and aren’t being deprecated just because there are other, newer APIs; and, at the same time, they want developers coming into the ecosystem fresh to find UWP first, so that UWP apps get built and make Windows tablet usage easier/better.
Mac OS X wasn't originally planned to have Carbon. Adobe basically told them there is no way they are completely re-writing all their apps for OS X. So Apple took another year, added Carbon, and Adobe ported Photoshop over.
Apple doesn't benefit from higher average quality of developers; they just benefited from having much fewer of them to support. The long tail of Windows is really really long -- businesses run on multi-million dollar software packages designed in the 90's. Apple has no such ecosystem.
The big ecosystem they do have (iOS apps) is very different and far more forgiving. There are thousands of unmaintained iOS apps that simply don't work anymore but they only cost $1.
Apple doesn't benefit from higher average quality of developers; they just benefited from having much fewer of them to support. The long tail of Windows is really really long -- businesses run on multi-million dollar software packages designed in the 90's. Apple has no such ecosystem.
The big ecosystem they do have (iOS apps) is very different and far more forgiving. There are thousands of unmaintained iOS apps that simply don't work anymore but they only cost $1.
While I agree with your premise (that Apple's lack of care or rigour for platforms likely stems mostly from having very few people to support), the specific story being provided for Carbon doesn't fit the history to me given that not only was iTunes written with Carbon (and was a holdout in switching to AppKit for a lot longer than Adobe), but so was Finder (a core piece of OS X, and that didn't transition until 10.6).
QuickTime Player was Carbon for a long time, too, and if I recall correctly so was iMovie.
It's in the Wikipedia article for Carbon:
https://en.wikipedia.org/wiki/Carbon_(API)
Apple's original plan was presented in 1997. Steve Jobs announced the "change of direction" in 1998. iTunes was released in 2001.
NeXTStep (and thus OpenStep and Rhapsody) already had a file browser/desktop application unrelated to the Finder.
https://en.wikipedia.org/wiki/Carbon_(API)
Apple's original plan was presented in 1997. Steve Jobs announced the "change of direction" in 1998. iTunes was released in 2001.
NeXTStep (and thus OpenStep and Rhapsody) already had a file browser/desktop application unrelated to the Finder.
It is true that iTunes and Finder were written in Carbon, but it is also true that Apple's original plan was for Yellow Box (the OpenStep API that later became Carbon) to be the main API for developing programs under Rhapsody, which was essentially NeXT with Mac OS 8 theming and UI guidelines. Rumor has it that Adobe and Microsoft balked at the prospect of having to port their applications to Yellow Box (there was no guarantee in 1997 that Apple's purchase of NeXT would pay off), which led to Apple announcing its Mac OS X strategy during WWDC 1998, which included Carbon as a first-class API for the development of Mac OS X applications alongside Cocoa (Yellow Box).
Regarding iTunes, one detail about Carbon that is sometimes forgotten is Carbon originally ran on Mac OS 8 and 9 to facilitate the transition to Mac OS X (https://en.wikipedia.org/wiki/Carbon_(API) ; to quote, "Carbon was introduced in incomplete form in 2000, as a shared library backward-compatible with 1997's Mac OS 8.1. This version allowed developers to port their code to Carbon without losing the ability for those programs to run on existing Mac OS machines.") Given that Mac OS 9 was still current when the first version of iTunes was released, it made sense for iTunes to be developed as a Carbon application (since Carbon applications can run on Mac OS 8 and 9 as well as Mac OS X) rather than as a Cocoa application (which can only run on Mac OS X).
Regarding iTunes, one detail about Carbon that is sometimes forgotten is Carbon originally ran on Mac OS 8 and 9 to facilitate the transition to Mac OS X (https://en.wikipedia.org/wiki/Carbon_(API) ; to quote, "Carbon was introduced in incomplete form in 2000, as a shared library backward-compatible with 1997's Mac OS 8.1. This version allowed developers to port their code to Carbon without losing the ability for those programs to run on existing Mac OS machines.") Given that Mac OS 9 was still current when the first version of iTunes was released, it made sense for iTunes to be developed as a Carbon application (since Carbon applications can run on Mac OS 8 and 9 as well as Mac OS X) rather than as a Cocoa application (which can only run on Mac OS X).
I remember reading an article on Rhapsody. I was then out of touch with the Mac world for a year or two, and I later started hearing about Mac OS X. The Adobe / MS story is well-known, but how was Mac OS X different from Rhapsody? It seems that Cocoa is a rebranded Yellow Box, and Carbon is a rebranded Blue Box. What was actually different?
Rhapsody didn't have Carbon, the Blue Box was a virtual machine that ran Mac OS 9 and the desktop interface was based on NeXTStep.
Actually the number of unmaintained apps is relatively tiny.
The reason being that Apple routinely forces developers to update their apps if they want to stay on the store.
The reason being that Apple routinely forces developers to update their apps if they want to stay on the store.
I encountered a few unmaintained apps -- again the long tail is long. Some failed in more and more ways with each new iOS version. Forcing developers to update their apps is exactly the issue, really.
There was a big cutoff in the transition to 64 bits; with a certain iOS release 32 bit apps just can’t run anymore.
> Apple benefits from having higher average quality of developers in its ecosystem
How can you conclude this with any sort of certainty?
How can you conclude this with any sort of certainty?
I have no empirical evidence for this of course, because there's no way to really measure this, AND it's getting more moot because of things like Electron.
But you can infer it historically by a few observations:
- More people intentionally get into mac software, than back themselves into it because it was for a job (like Windows/.NET development). So there's a quality vs quantity argument there.
- Just use independent windows applications vs mac applications. There's almost always a much higher level of fit and finish on the Mac side.
- Judging by how quickly a lot of iOS apps start to adopt newer frameworks and technologies
But you can infer it historically by a few observations:
- More people intentionally get into mac software, than back themselves into it because it was for a job (like Windows/.NET development). So there's a quality vs quantity argument there.
- Just use independent windows applications vs mac applications. There's almost always a much higher level of fit and finish on the Mac side.
- Judging by how quickly a lot of iOS apps start to adopt newer frameworks and technologies
I'm an iOS developer, I've been coding the platform since iOS 3, and I'm a .Net developer coding in C# since Beta 1.
Initially that argument was slightly true. But has long since passed and is completely bullshit now. As soon as it was apparent there was a goldmine in iOS development the floodgates opened wide. There is zero difference between the average Windows developer and the average iOS developer anymore, and there hasn't been since at least iOS 5. (most likely iOS 4)
Initially that argument was slightly true. But has long since passed and is completely bullshit now. As soon as it was apparent there was a goldmine in iOS development the floodgates opened wide. There is zero difference between the average Windows developer and the average iOS developer anymore, and there hasn't been since at least iOS 5. (most likely iOS 4)
Sure, iOS software has no bar. How about macOS software, though? Or tvOS, or watchOS? You know, the platforms that aren’t goldmines :)
MacOS apps are mostly made by cross-platform devs, and it's not exactly a great experience. Half the trouble is figuring out how to put something together that makes sense on both Windows and MacOS.
That's likely true for the long tail of mediocre developers (whereas there probably wasn't as much of a long tail before on the Mac side).
On the Mac, it's a bit different. Take a look a longtime Mac software boutiques like Panic and Rogue Amoeba.
It's interesting that I can't reel off Windows equivalents of those companies. Where are the companies that embrace the and celebrate the Windows platform like Panic or Omni Group?
There really is very little to celebrate in Windows. OSX had/has a belief in quality (even if Apple didn’t always live up to it, and lately they’ve shredded the HIG altogether) that inspired devotion in a way Windows never could.
In addition, OSX has always had a strong culture of customers willing to pay for quality software, that has allowed independent smaller companies to flourish. There is no such equivalent in Windows. The Windows culture appears to be one of providing shareware, that was cracked and used for free by individuals, and developers were ok with it because they actually made money from enterprise users who would pay up.
In addition, OSX has always had a strong culture of customers willing to pay for quality software, that has allowed independent smaller companies to flourish. There is no such equivalent in Windows. The Windows culture appears to be one of providing shareware, that was cracked and used for free by individuals, and developers were ok with it because they actually made money from enterprise users who would pay up.
I disbelieve having software cracked are favorable by any developers who spent countless sleepless nights coding with sweat and blood
Not a multi-person company like the ones mentioned but Bvckup https://bvckup2.com/ and its developer comes to mind, especially for their dedication and attention to detail https://bvckup2.com/wip/
Frameworks I have used for UI work on Windows include MFC, ATL, WTL, WinForms, WPF, UWP and pure win32. After a while you kind of get burnt out on the never ending changes.
Apple might force you along but they seem to have fewer transitions overall and a much clearer strategy.
Apple might force you along but they seem to have fewer transitions overall and a much clearer strategy.
That is exactly why I use Delphi when doing GUI apps on Windows. Single GUI framework that works like a charm for more then 20 years. It is very unfashionable to say mildly but it is the fastest tool to get things done for Windows GUI apps.
You could equally just pick one of the above commentor's list and use it for 20 years (minus a few for the relatively new ones). They all still work, whereas when Apple transitions they remove the old option.
I actually tried most and ended up with Delphi as ticking most checkboxes in my big list list. Granted I am an ISV and could care less about what other think about popularity of the tools I choose. Always pick what suits me. As for finding developers: that does not seem to be a a problem if one knows how/where to look.
That can be a problem as well. My main product is a WinForms app and I have spent a huge amount of time making it work well on high-dpi screens.
I feel like I hit the sweet spot by only ever using WinForms, then getting out.
Their framework strife seems like a manifestation of their depiction in this classic: http://bonkersworld.net/organizational-charts
Their framework strife seems like a manifestation of their depiction in this classic: http://bonkersworld.net/organizational-charts
Is WPF still a good option? It looked like Microsoft put a lot of weight behind that for a while, they even made parts of Visual Studio in it. But I haven't heard anything about it for years, I guess it got replaced by UWP? Does UWP use XAML too?
UWP is getting better but last time I looked it still had some weird restrictions. For many things WPF is still your best bet because you can be pretty confident that you will be able to do what you need to do.
"Apple benefits from having higher average quality of developers in its ecosystem"
What?! How on earth do you come to that conclusion?
What?! How on earth do you come to that conclusion?
I think the difference is in the second step. Both companies excel in moving the target forward, but Microsoft rarely, if ever, shuts off access to the old targets, maintaining compatibility essentially forever, which keeps them from ever being able to make major transitions.
There are any number of ways to develop for Windows, and the fact that many, even most developers use Visual Studio is different from the Apple approach: everybody must use Xcode. This sucks for companies like MetroWerks that once developed a popular IDE for MacOS only to be shut out, but it's necessary to ensure that the tail end of the migration, that pesky step 2 of shutting things off, happens.
There are any number of ways to develop for Windows, and the fact that many, even most developers use Visual Studio is different from the Apple approach: everybody must use Xcode. This sucks for companies like MetroWerks that once developed a popular IDE for MacOS only to be shut out, but it's necessary to ensure that the tail end of the migration, that pesky step 2 of shutting things off, happens.
Apple is better about clarity (or, being dogmatic if you prefer that view).
You are right, MSFT has done a great job, but they made enough of a mess in the '00's that they kicked out their CEO and put in Nadella.
Thankfully, Nadella seems to understand the importance of making things clear to make things simple for people. I hope to see that continue. Microsoft of the 90's still seems a long time ago (but sure looks like Apple today!)
Developer quality of MSFT in the 90's and AAPL today is probably a wash (except for that everyone has been around computers for years now - that wasn't true in the 90's).
You are right, MSFT has done a great job, but they made enough of a mess in the '00's that they kicked out their CEO and put in Nadella.
Thankfully, Nadella seems to understand the importance of making things clear to make things simple for people. I hope to see that continue. Microsoft of the 90's still seems a long time ago (but sure looks like Apple today!)
Developer quality of MSFT in the 90's and AAPL today is probably a wash (except for that everyone has been around computers for years now - that wasn't true in the 90's).
Whether there are a lot of Indy developers on the Mac doesn’t matter. If Microsoft’s and Adobe’s software don’t run on a new Mac platform, it’s a non starter.
You saw that in each transition:
68K -> PPC -> Intel
And
Classic MacOS -> Carbon -> Cocoa -> 32 bit -> 64 bit
You saw that in each transition:
68K -> PPC -> Intel
And
Classic MacOS -> Carbon -> Cocoa -> 32 bit -> 64 bit
> You saw that in each transition:
No, those transitions started (and became sure things) long before there was any commitment from "A-list" developers to support them. Getting commitment was an orthogonal task, and itself took significant technical and relationship work from both Apple and the developers. (Note: I was in developer relations for a few of these transitions.)
> Whether there are a lot of Indy developers on the Mac doesn’t matter.
Indie developers matter, not least of which because they're typically the first to adopt new Apple-only technologies.
No, those transitions started (and became sure things) long before there was any commitment from "A-list" developers to support them. Getting commitment was an orthogonal task, and itself took significant technical and relationship work from both Apple and the developers. (Note: I was in developer relations for a few of these transitions.)
> Whether there are a lot of Indy developers on the Mac doesn’t matter.
Indie developers matter, not least of which because they're typically the first to adopt new Apple-only technologies.
No, those transitions started (and became sure things) long before there was any commitment from "A-list" developers to support them.
The famous deal where Microsoft promised to keep bringing Office to the Mac for five years was in 1997. Those five years encompassed the classic MacOS to OS X transition. Apple’s five year roadmap was far from a secret to developers.
The whole Carbon API for OS X was done after major developers insisted on it to bring their apps to OS X.
Adobe and Microsoft committed to port their software to x86 when Apple announced the transition in 2005.
Heck Microsoft was on stage committing to the Mac in 1984.
The famous deal where Microsoft promised to keep bringing Office to the Mac for five years was in 1997. Those five years encompassed the classic MacOS to OS X transition. Apple’s five year roadmap was far from a secret to developers.
The whole Carbon API for OS X was done after major developers insisted on it to bring their apps to OS X.
Adobe and Microsoft committed to port their software to x86 when Apple announced the transition in 2005.
Heck Microsoft was on stage committing to the Mac in 1984.
> The famous deal where Microsoft promised to keep bringing Office to the Mac for five years was in 1997.
I believe you're conflating "Apple needing an Office story to sell to enterprise" with "Apple needing pre-commitment from Microsoft before implementing a hardware or OS transition". Those transitions would've happened regardless of whether we lost a few A-list developers.
Apple did not ask permission from developers before deciding to advance their platform.
I believe you're conflating "Apple needing an Office story to sell to enterprise" with "Apple needing pre-commitment from Microsoft before implementing a hardware or OS transition". Those transitions would've happened regardless of whether we lost a few A-list developers.
Apple did not ask permission from developers before deciding to advance their platform.
They didn’t “ask permission” but they did work with third party developers.
But in fact, major developers vetoing the idea of porting directly to Objective C from day one gave rise to Carbon.
But in fact, major developers vetoing the idea of porting directly to Objective C from day one gave rise to Carbon.
SwiftUI looks like it can bridge that final gap I’ve had with my Metal and SpriteKit projects, which were almost entirely cross platform. There will still likely be distinctions in touch handling vs mouse — I haven’t had time to fully explore SwiftUI yet — but I’m looking forward to simplifying the code even further.
> which were almost entirely cross platform...
Cross-platform Metal and SpriteKit? Wouldn't it be better to code against Vulkan (== MoltenVK) or OpenGL if being cross platform is the goal?
Or do you mean "cross platform" as for example Microsoft has often done. Within their platforms.
Current difficulty of developing native cross platform projects is depressing. You have to use domain specific tools like Unity, React Native, etc. Or just target the web browsers.
Cross-platform Metal and SpriteKit? Wouldn't it be better to code against Vulkan (== MoltenVK) or OpenGL if being cross platform is the goal?
Or do you mean "cross platform" as for example Microsoft has often done. Within their platforms.
Current difficulty of developing native cross platform projects is depressing. You have to use domain specific tools like Unity, React Native, etc. Or just target the web browsers.
Correct, within the Apple ecosystem — Mac, iOS.
So not so much cross platform as it’s commonly used, but rather multi-targeting within the Apple-platform.
Mac OS / iOS / tvOS / WatchOS are certainly different platforms. The iPhone and the Mac are very different products with very different use cases, so of course they are different platforms.
It's not "all-platform", but this is definitely "cross-platform".
It's not "all-platform", but this is definitely "cross-platform".
He probably means in the way that Apple means it with SwiftUI and Catalyst. Cross-platform = Apple devices (i.e. macOS, iOS, iPadOS, watchOS, tvOS)
There's far more to building a cross platform app than making sure the UI fits on both screens. I might have missed it but does Apple plan to consolidate things like file system, networking, installation lifecycle, and notifications?
The core APIs are the same, so you get most things for free — file system, networking, media recording/playback, graphics, and more.
Installation takes place before the app gets to run any code. Notifications are similar enough to be hidden under a tiny abstraction (macOS even supports Push notifications, although I’m not aware of any app that uses them).
Really, UI was the only area where you could feel like you’re developing for different operating systems.
How does SwiftUI help for other platforms? Genuinely curious if this will work on Windows, Linux & Android too? So far it looks like it is entirely targeted at the mac ecosystem (aka we-want-all-our-software-to-look-like-iOS ecosystem)
SwiftUI is just one instance of a new feature in Swift called function builders that allows creating custom DSLs within Swift. As Swift’s cross-platform support grows, two things can happen: SwiftUI can be customized go work with the GUI toolkits of other systems, and other system-specific DSLs can be developed to take advantage of each system’s own unique capabilities and APIs.
I think the likely scenario here would be a swiftUI-like framework which is cross platform. SwiftUI is tightly coupled with Apple’s UI rendering system, and they have no incentive to make it easier to port iOS code to Android for example.
> [Catalyst/SwiftUI] provides iOS developers with a familiar set of tools and access to an entirely new platform
Rather think that's the wrong way round. Whilst it might be true in the short term, it's really part of the MacBook/MacOS obsolescence plan. The next generation of MacBooks - whatever they're called - will be an evolution of ipad, using ARM hardware and running an iOS-derived OS. The recent creation of ipadOS is another symptom of that transition.
Not that it changes the central thrust of the piece: that Apple does slow, sustained, steady evolution well. But Catalyst/Swift aren't primarily about giving developers access to an extra platform; it's to make sure there's a ready-made market of apps and developers when the macbook range as we know it goes away.
Rather think that's the wrong way round. Whilst it might be true in the short term, it's really part of the MacBook/MacOS obsolescence plan. The next generation of MacBooks - whatever they're called - will be an evolution of ipad, using ARM hardware and running an iOS-derived OS. The recent creation of ipadOS is another symptom of that transition.
Not that it changes the central thrust of the piece: that Apple does slow, sustained, steady evolution well. But Catalyst/Swift aren't primarily about giving developers access to an extra platform; it's to make sure there's a ready-made market of apps and developers when the macbook range as we know it goes away.
> The next generation of MacBooks - whatever they're called - will be an evolution of ipad, using ARM hardware and running an iOS-derived OS.
No they won't. I mean, it's conceivable that they could be using ARM chips (though Apple would need a strategy for emulating x86_64 in this case, like they did for PowerPC->i386), but there's no way they're going to be running iOS.
Apple is slowly expanding the capabilities of the iPad, that's certainly true, but it's not even close to replacing a laptop for all tasks. iPads are becoming usable for more and more tasks, but there's a very long way to go before the laptop is obsolete, and I don't expect iPad to ever actually go that far (if it did, it would just end up being a laptop). Even given laptop hardware, iOS is not set up to be able to replace macOS for all tasks.
Even ignoring all that, Catalyst is if anything evidence to the contrary, that Apple sees macOS as being very much alive and wants to encourage more apps to be developed for it. Catalyst isn't just iOS apps on macOS, it's also tools to extend your iOS codebase to adopt macOS-specific features, like multiple overlapping windows of arbitrary sizes, menu bars, a mouse¹, titlebar controls, and more.
¹I know iOS 13 now supports using a mouse on iPadOS, but it's just an accessibility feature that looks to the app like a touch, it doesn't e.g. support hover states, or encourage smaller click targets, or anything like that.
No they won't. I mean, it's conceivable that they could be using ARM chips (though Apple would need a strategy for emulating x86_64 in this case, like they did for PowerPC->i386), but there's no way they're going to be running iOS.
Apple is slowly expanding the capabilities of the iPad, that's certainly true, but it's not even close to replacing a laptop for all tasks. iPads are becoming usable for more and more tasks, but there's a very long way to go before the laptop is obsolete, and I don't expect iPad to ever actually go that far (if it did, it would just end up being a laptop). Even given laptop hardware, iOS is not set up to be able to replace macOS for all tasks.
Even ignoring all that, Catalyst is if anything evidence to the contrary, that Apple sees macOS as being very much alive and wants to encourage more apps to be developed for it. Catalyst isn't just iOS apps on macOS, it's also tools to extend your iOS codebase to adopt macOS-specific features, like multiple overlapping windows of arbitrary sizes, menu bars, a mouse¹, titlebar controls, and more.
¹I know iOS 13 now supports using a mouse on iPadOS, but it's just an accessibility feature that looks to the app like a touch, it doesn't e.g. support hover states, or encourage smaller click targets, or anything like that.
>No they won't. I mean, it's conceivable that they could be using ARM chips (though Apple would need a strategy for emulating x86_64 in this case, like they did for PowerPC->i386)
Exactly. Apple has proven it can do emulation very successfully - it's already done it twice (M68K->PPC->x86)
> there's no way they're going to be running iOS
I didn't say "running iOS", I said "an iOS-derived OS".
>Catalyst is if anything evidence to the contrary, that Apple sees macOS as being very much alive and wants to encourage more apps to be developed for it.
That's the other interpretation. I don't see it personally: the central thrust of the article is that Apple is really good at gentle evolution. MacOS has seen no meaningful innovation in years. iOS, by comparison, has evolved significantly. It's been steadily gaining more features that move it towards being a laptop-capable OS (e.g. multi-tasking). It's certainly not there yet - but that's the trajectory.
To be clear, when I said "next generation macbooks" I didn't mean "next revision". It's probably several revisions away and it'll happen incrementally.
Still, of course, it's just opinion :). Thanks for sharing yours.
Exactly. Apple has proven it can do emulation very successfully - it's already done it twice (M68K->PPC->x86)
> there's no way they're going to be running iOS
I didn't say "running iOS", I said "an iOS-derived OS".
>Catalyst is if anything evidence to the contrary, that Apple sees macOS as being very much alive and wants to encourage more apps to be developed for it.
That's the other interpretation. I don't see it personally: the central thrust of the article is that Apple is really good at gentle evolution. MacOS has seen no meaningful innovation in years. iOS, by comparison, has evolved significantly. It's been steadily gaining more features that move it towards being a laptop-capable OS (e.g. multi-tasking). It's certainly not there yet - but that's the trajectory.
To be clear, when I said "next generation macbooks" I didn't mean "next revision". It's probably several revisions away and it'll happen incrementally.
Still, of course, it's just opinion :). Thanks for sharing yours.
> Apple would need a strategy for emulating x86_64 in this case
Depending on how they roll out this transition they might not need x86_64 emulation. It is a very useful feature, but not for everybody. I am pretty sure most of the current programs distributed through MacApp store could be ported to ARM relatively easily, especially if they depend mostly on system frameworks.
Open source CLI and developer tools already run well on ARM as ARM linux computers are nothing new.
Big players such as Adobe do already know how to build ARM applications as they already ship them on iOS and presumably would have a good head start to port their flagship programs.
Finally I am convinced that internally Apple has already all of their software including macOS and Xcode running on ARM (OS X was running on Intel from the beginning, years before the transition).
With all of that, it is pretty conceivable that Apple would push out _a_ machine with an ARM chip, simply running an ARM build of macOS.
Depending on how they roll out this transition they might not need x86_64 emulation. It is a very useful feature, but not for everybody. I am pretty sure most of the current programs distributed through MacApp store could be ported to ARM relatively easily, especially if they depend mostly on system frameworks.
Open source CLI and developer tools already run well on ARM as ARM linux computers are nothing new.
Big players such as Adobe do already know how to build ARM applications as they already ship them on iOS and presumably would have a good head start to port their flagship programs.
Finally I am convinced that internally Apple has already all of their software including macOS and Xcode running on ARM (OS X was running on Intel from the beginning, years before the transition).
With all of that, it is pretty conceivable that Apple would push out _a_ machine with an ARM chip, simply running an ARM build of macOS.
If iOS gains enough features to replace macOS, then it will just be macOS again. iOS is gaining new features, but it's still a rather constrained and touch-focused environment. For example, you can do split-screen on iPadOS, but you can't do arbitrary overlapping windows. Instead they're focusing on ways to save "scenes" and switch between apps, but each app still owns the portion of the screen it's been given (and those portions are very constrained; full-size, half, 1/3rd, or a slightly shorter 1/3rd in a slide-over; and the 1/3rd size is literally supposed to be your iPhone UI). They added mouse to iPadOS but strictly as an accessibility feature, and apps can't even detect that the mouse is there, let alone add mouse-related functionality. The file system is still heavily locked down. There's still no process spawning or any indication that Apple will ever allow process spawning (which is a hard blocker for a lot of developer tools). iPads support external screens, but not as the primary display (that's basically just for projecting stuff, e.g. presentations or photos).
Ultimately, there's no point in relaxing these restrictions for an "iOS-derived" laptop OS. The primary argument in favor of unifying macOS and iOS was the fact that iOS has a lot of developer momentum and that way you can use iOS apps on macOS, but that's exactly what Catalyst gives us already. Apple is working towards unifying stuff at the developer API level (e.g. Catalyst, SwiftUI, etc) but at the OS level macOS and iOS are quite distinct and will stay that way.
Ultimately, there's no point in relaxing these restrictions for an "iOS-derived" laptop OS. The primary argument in favor of unifying macOS and iOS was the fact that iOS has a lot of developer momentum and that way you can use iOS apps on macOS, but that's exactly what Catalyst gives us already. Apple is working towards unifying stuff at the developer API level (e.g. Catalyst, SwiftUI, etc) but at the OS level macOS and iOS are quite distinct and will stay that way.
”Apple has proven it can do emulation very successfully - it's already done it twice (M68K->PPC->x86)”
In both cases, from a situation where the platform being emulated was seriously behind, performance-wise.
I don’t think they can maneuver themselves in that position for a x86 ⇒ ARM migration (not even given that they can tweak their ARM variant)
Luckily, I don’t think they would need emulation. Many of their customers don’t run anything else than Apple’s software or popular open source apps that would be migrated within a few days on their Macs.
The others will have to wait until the likes of Adobe have ported their software.
In both cases, from a situation where the platform being emulated was seriously behind, performance-wise.
I don’t think they can maneuver themselves in that position for a x86 ⇒ ARM migration (not even given that they can tweak their ARM variant)
Luckily, I don’t think they would need emulation. Many of their customers don’t run anything else than Apple’s software or popular open source apps that would be migrated within a few days on their Macs.
The others will have to wait until the likes of Adobe have ported their software.
Where Apple says something is an OS, they really mean it as a distinct user experience.
They want to make the infrastructure that applications rely on as similar as possible, including UI efforts like Catalyst and SwiftUI. But at the same time, they know that the user interface on a iPhone is fundamentally different than what is shown on a TV. They added Xbox/dualshock controller support specifically for tvOS - but wound up adding it to iPhone and iPad since they were really adding to the underlying platform.
They want to make the infrastructure that applications rely on as similar as possible, including UI efforts like Catalyst and SwiftUI. But at the same time, they know that the user interface on a iPhone is fundamentally different than what is shown on a TV. They added Xbox/dualshock controller support specifically for tvOS - but wound up adding it to iPhone and iPad since they were really adding to the underlying platform.
TLDR: over time, Apple transitions from one technology/development platform to another. author calls this an "invisible" strategy because... it's done properly and methodically.
I can’t think of a single transition that Apple botched. They even had a good transition strategy from the Apple //e to Mac for users with the //e card.
Apple II->III? Mac->Copland? Mac->Taligent? Apple IIgs->Mac? HyperCard->(nothing)? Carbon 32b->64b (as originally promised)? FCP 7->X? iMovie HD->08? iWork '09->2013? Mac Pro 2012->2013->2019?
It depends on your definition of "botched", but I can think of lots of examples of cases where Apple either gave up, or essentially reverted their changes, in the face of public outcry or technical hurdles.
I wouldn't really call the IIe card a "transition strategy", either, any more than Mac86 was. It was a kluge to add another entire computer as an add-on card. It didn't help move your programs or data at all. It also only emulated a IIe (8 years old at that point), not a IIgs (only 5 years old). It was only a 'transition' for the absolute penny-pinching-est buyers, i.e., education.
It depends on your definition of "botched", but I can think of lots of examples of cases where Apple either gave up, or essentially reverted their changes, in the face of public outcry or technical hurdles.
I wouldn't really call the IIe card a "transition strategy", either, any more than Mac86 was. It was a kluge to add another entire computer as an add-on card. It didn't help move your programs or data at all. It also only emulated a IIe (8 years old at that point), not a IIgs (only 5 years old). It was only a 'transition' for the absolute penny-pinching-est buyers, i.e., education.
I am quite curious about the HyperCard thing. I've come to the Apple ecosystem quite late so I have never experienced this but it looks like some of the current design tools such as InVision and also Powerpoint/Keynote. Am I mistaken? What made HyperCard so great? If it was so powerful why isn't there an extremely popular alternative? It does not look like something only Apple could ship.
The Apple III was backwards compatible with the Apple //.
Copland and Taligent never shipped to developers or users so neither wasted time on it.
I had an Apple //e card. Using the included software, you could setup a ProDOS partition on your hard drive, and copy files from the //e to the Mac. Apple bundled converters that you could use to convert AppleWorks documents to Mac app documents.
Mac86 sucked but the DOS Compatibility Card for the PowerMac 6100/60 with a 486DX/2, a dedicated sound card, and the capability of adding 32MB of dedicated RAM was quite good until Windows 95 came out and it could only use 16 bit drivers. That was my second Mac.
Copland and Taligent never shipped to developers or users so neither wasted time on it.
I had an Apple //e card. Using the included software, you could setup a ProDOS partition on your hard drive, and copy files from the //e to the Mac. Apple bundled converters that you could use to convert AppleWorks documents to Mac app documents.
Mac86 sucked but the DOS Compatibility Card for the PowerMac 6100/60 with a 486DX/2, a dedicated sound card, and the capability of adding 32MB of dedicated RAM was quite good until Windows 95 came out and it could only use 16 bit drivers. That was my second Mac.
Some of your examples are pertinent, but I think calling MacOS->Copland, MacOS->Taligent, HyperCard->(nothing) "botched transitions" is a bit disingenuous.
Copland never shipped, and as such was not a transition at all, because the public was not directly involved in the internal failure. Taligent basically never shipped anything, and so the same argument applies.
The replacement OS that Apple actually shipped (OS X) aided a legacy transition that I think went down basically as well as it possibly could have (given the inherent dissimilarities between the two OSes).
HyperCard was merely killed off, so there was clearly no transition at all. That's like saying Newton->(nothing) failed as a transition.
Copland never shipped, and as such was not a transition at all, because the public was not directly involved in the internal failure. Taligent basically never shipped anything, and so the same argument applies.
The replacement OS that Apple actually shipped (OS X) aided a legacy transition that I think went down basically as well as it possibly could have (given the inherent dissimilarities between the two OSes).
HyperCard was merely killed off, so there was clearly no transition at all. That's like saying Newton->(nothing) failed as a transition.
The transition to PowerPC only worked, as I recall, because Metrowerks wrote a compiler to handle the heavy lifting.
Non-PowerPC software was run in emulation: https://en.wikipedia.org/wiki/Mac_68k_emulator
But yes, Metrowerks saved their bacon by providing the only PowerPC compiler for quite a long time, IIRC.
But yes, Metrowerks saved their bacon by providing the only PowerPC compiler for quite a long time, IIRC.
Yes, and the emulation was awful prior to the G3
As long as you ignore the whole 68K emulation that was built in.
ObjC Garbage Collection comes to mind.
How many developers actually wrote code using garbage collection that had a hard time updating to ARC?
Ok well if your metric for "botched" is that developers had a hard time, the general 32-bit Carbon to 64-bit AppKit transition would have to count. :) App Sandbox perhaps too...
Not sure I'd call sandboxing a "botched transition"–many developers found it so onerous that they've been holding off on it for almost a decade :)
Apple has never described Swift, Catalyst, or SwiftUI as a transition from or to anything. Instead, Apple has gone out of its way to say that these are not transitions. Remember that big "NO" slide from last year?
When a transition is required, Apple does not ever hide it.
Classic Mac to OS X was a transition.
PPC to Intel was a transition.
UIWebView to WKWebView is a transition.
SwiftUI is no more a transition from AppKit/UIKit than Storyboards were a transition from NIBs and programmatic UI.
Modern ObjC syntax, Enterprise Objects, Java/Cocoa Bridge, Ruby/Cocoa, Python/Cocoa, Key-Value Observing/Encoding, ObjC Garbage Collection, ARC, Storyboards, Playgrounds, Swift, SwiftUI, etc. These are not transitions. These are all just tools in the toolbox. Some more useful than others.
The only thing Apple's engineers are trying to do here is create stuff that developers find useful. There is no hidden or invisible strategy with this stuff.