Swift 5.3 with official Windows support:
I guess I missed “official windows support”. I saw a Windows Release Manager named, but hey Swift has been “available” for windows for a while now… but not with any real “gui” support…
UI bindings are the real stumbling block but … its getting there
In addition, this release will expand the number of platforms where Swift is available and supported, notably adding support for Windows and additional Linux distributions.
means it’s officially supported with Swift 5.3 and not just available.
I guess with Microsoft bringing VisualStudio to the Mac they felt they have to take Windows seriously to keep the reigns on where they want programming to go (a bit similar to bringing CPU design in-house).
Ooh nice find. There has been a community supporting Windows compilation for a while but it’s always behind the main branch. This is excellent news. Just need some clever person to provide a way to write the Win32 API and Xojo is in big trouble.
Yeah if this, or Xamarin or any of the other tools from big names had a decent UI builder thaey might just find they get a pile of Xojo refugees
The #1 reason (IMHO) for a macOS developer to consider Swift, is to use Catalyst today.
I have a horrible gut feeling that Catalyst is being provided as a means to get macOS developers to migrate over so that in the next year (or several) we’re all making iPadOS apps that work on ARM iPads and x86 Macs, until ARM Macs are here which will only run ARM iPad apps.
I hope that I’m wrong… I came to this conclusion based on ARM Mac rumors are really gaining moment, so I couldn’t understand how Catalyst was going to fit in, until I realized that it might be a stopgap solution, to get us ready for ARM.
I’m just starting out with Swift (and am delighted that official Windows support has been added for Swift 5.3) but that implies that you consider another language much more suitable and superior to Swift. So I’m curious: Which one and why?
My thoughts exactly. At first this filled me with dread - the thought of iPad apps shoehorned into the macOS app ecosystem seems horrible except having taken a closer look at the newly released iPad and the (ridiculously priced) keyboard with trackpad, I can certainly see a way forwards for iPadOS to become pretty darn usable…
If I had to change languages today, I’d choose Swift. But only because going forwards it’s going to be the ONLY language that Apple supports.
If Apple was going to continue to maintain Swift and Objective-C, I’d pick Objective-C in a heartbeat. But that’s probably because I’ve spent decades slowly learning it so I can do declares and write basic sample apps to test when stuff doesn’t work in Xojo.
I still don’t get this though:
Sure, More developers is not a bad thing …
… but I would disagree with this:
While the underlying logic and code might be shared, there will be differences too. I’d say it becomes more akin to Xojo for Mac and Windows. Especially as they are going to officially support Swift for Windows too.
And which developer would restrict him/herself to “iOS apps for Macs” - that would be a serious disadvantage.
Not to mention the huge installed base of Macs.
Until Xcode is available on an iPad I’m not too concerned
I came to this conclusion because of various factors.
I’ve witnessed 5 transitions from Apple, 68K -> PPC -> OS X -> Intel 32-Bit -> Intel 64-Bit, each time causes upheaval, then the platform recovers as developers recover, and it grows again. Generally you want to give it some time to mature, before tearing it down again. However this ARM transition isn’t giving it very long since Catalina wiped out a whole bunch of apps and pissed people off. Doing another transition so soon, will cost them frustrated customers.
It’s not about power or performance. If it were, Apple would have made one or more of the following changes.
a) Used latest Intel processors when they became available (Apple used to do this). Apple even let products go for up to 4 years without a change.
b) Design their hardware to reduce thermal throttling, this seems to have changed with the 16" MBP, but many other products are still thermally “challenged”.
c) If they really want more power/performance than Intel can provide, they’d swap to the later AMD Threadripper chips, maybe point b) makes it harder for them to do so?
It’s not about quality.
a) In 2016, when Apple released the Touchbar MacBook Pro, they knew the keyboard was unreliable, yet they rolled it out to every Mac laptop. Each year, they claimed to fix it, doing the absolute minimum, and failed. The repair program replaced like for like, so you’d just get another keyboard that’s also highly likely to fail. There’s been no official apology, to make matters worse, their trade in program, will give you less money if your Butterfly keyboard is faulty.
b) The 2017 & 2018 MacBook Pros have issues with external Thunderbolt accessories. I’ve seen several people who’ve had to fight Apple, tooth and nail to get a working unit.
d) Apple is aware that the macOS has become fragmented (something they criticized Android for), forcing developers like us to support more versions than previously, with each version having it’s own set of issues that developers have to basically discover and devise workarounds for.
Which leaves me with one reason that I can think of. Cost.
- Why after decades, does Apple stop releasing unit numbers, only focusing on “Profit”?
- Buying more ARM chips from TSMC, increases their volume and reduces the cost per unit.
- Low end Macs can then use a slightly modified (may not even need to be modified) iPad logic board, reducing costs.
- iOS gets the most love from Apple, by completely replacing the macOS with a fork of iOS, this will save costs (and time) in OS development. This has been ongoing for years already, as illustrated by bugs appearing in the macOS that have existed on iOS for years, or limited iOS frameworks replacing macOS frameworks, without consideration for the more powerful previous version in the macOS.
- Once all the OSes are basically iOS, Apple can save costs (and time) by reducing the number of developers it needs to develop Apple apps. As Apple Apps will all be the same underneath, just with different GUI theme and layout, it may even be automated, so that one interface designer can easily make an interface that spans all Apple platforms.
So IMHO, the potential ARM transition is done to improve ROI, and to be honest, it does make sense from a logical point of view.
For those existing Intel based Macs out there that can run Catalina (or newer), they’ll be able to use Catalyst based apps. I’d imagine, that the Mac Pros will stay on x86 for a while, mainly for high core count chips.