Apple’s use of Swift and SwiftUI in iOS 14
blog.timac.org
blog.timac.org
I made the mistake of choosing iOS and SwiftUI for the first platform of a niche app, a few months ago. Trying to do things in the way Apple wants seems a good strategy in general, but the experience was bad in countless ways. The developing&publishing approval barrels don't help. I succeeded, but only by throwing vastly more experience and energy at it than should've been necessary.
One of the engineering culture surprises was realizing that a lot of iOS developer chatter seemed to be repeating PR talking points, rather than the frank critiques that I'd expect in analogous situations in many other software development communities.
Besides a theory of fandom or Stockholm Syndrome, or dreaming of a job at Apple, or fearing being deplatformed... maybe there's an incentive for someone with hard-earned knowledge in something marketable to play along and be reassuring about their own expertise in it?
This tends to be overestimated. There's rarely a good reason to fear criticism. Apple is too huge to notice you, unless you're famous yourself. Also, Apple is a very bureaucratic organization especially now. The App Store editorial team is in its own silo and doesn't necessarily pay attention to this, and isn't influenced by other teams within Apple (except when top executives step in, of course).
Ironically, the rational fear of criticizing Apple comes not from Apple retribution but rather from all the random little Apple fans jumping all over you for criticizing Apple.
And SwiftUI is at least one level above that, so it’s going to be some time before it’s stable enough to get that spit and shine properly.
I’m off to muck about in the internal view hierarchy of a navigation bar to animate its button label..
You've already made up your mind if you're just going to slap such labels upon anyone who disagrees. Frank critique doesn’t thrive in echo chambers, and your preemptive polarization is just as guilty of such bias, just in the other direction.
What term should we use for your camp? "Haters?" "Lazy devs who don't bother to learn the intricacies of a new platform and expect stale knowledge they studied 10 years ago to apply everywhere?"
Electron is that way and have a nice day.
> Your comment is refreshing.
jamil7's GP comment was literally 2 sentences just saying "I'm disappointed, half-baked, bugs."
Disappointed how? Half-baked how? No details, just a string of some negatives and that's enough to make you happy. "Someone who agrees with me! Everyone else must be an Impostor!" (little Among Us reference there)
SwiftUI is a monumental project. Does any serious developer with real-world experience expect long-standing technologies like AppKit/UIKit/Cocoa/etc. to be completely supplanted within 2 years?
Any developer worth their bits would immediately notice the extensive support for incrementally adopting SwiftUI in legacy projects, or selectively falling back to existing tech in SwiftUI projects. You’re not supposed to go all-in if you're not fully comfortable with it, or if it doesn't serve all your needs yet.
And anyone even casually glancing at Apple SDKs will sense that this -is- the future. It's honestly fucking amazing to be able to target macOS, iOS, iPadOS, tvOS, watchOS and soon the rumored AR glasses with like 70% or more of the same code. Best of all, it not just spits out native widgets on each device (unlike Flutter or Qt), but also automatically adapts to the paradigms of each form factor (like navigation pages on phone/watch/TV versus sidebars on Mac/iPad).
Not to mention the rich support for adding internationalization and accessibility features to your app at a low cost, something that other major frameworks and companies generally ignore.
Yes, there are bugs. Yes, the documentation is appalling in many places. Yes, Apple doesn't communicate very well.
But hot damn, SwiftUI is the most refreshing UI framework I've seen since WPF, which Microsoft didn't even dogfood as much as Apple has done with their tech (both Swift and SwiftUI are already being used in core features of their OSes).
Shit that would take me a week on other frameworks I can now throw together in a day with SwiftUI, live previewing and incrementally improving and targeting multiple devices as I go.
I am not going back to any other framework. I would rather put my projects on hold if SwiftUI cannot handle them in its current state, than the other way around. The grass may seem greener on the other side for now but only because it's growing from a pile of rotting cow turds.
How's that for Frank Critique
Fundemental building blocks of SwiftUI are broken and have been since it's annoucement, List, NavigationView and NavigationLink for example – these are the basis of SwiftUI apps and need attention from Apple developers, I've reported bugs, memory leaks and performance issues with these and they've been acknowledged, maybe they fix them during iOS14's lifecycle but maybe not. We got some much needed features at this years WWDC but I would have also liked to see these fundementals addressed and maybe even rethought (navigation). It's not like we're talking about a volunteer open source project here, we're talking about the future flagship UI framework for 2 trillion dollar company. Run and profile Apple's own Fruta example app if you want to see what I'm talking about.
When it works, then yes like I said I can't imagine a faster way of building for Apple platforms. But right now I would warn others not to adopt it at any meaningful scale for another 2 years.
Apple's lack of documentation and communication doesn't help; the best resources have been from fellow developers who were groping around in the dark like the rest of us and managed to figure things out by themselves. [0,1]
But again, I've already been able to do many things in SwiftUI that I don't even want to attempt in AppKit/UIKit/other frameworks.
Right now I think it's good enough for small apps or personal convenience tools. One surprising application for it is in games, where it actually works quite well, compared to all the other alternatives for drawing scalable/animatable HUDs and text etc. [2]
In an year or two I don't think anyone would willingly choose to fumble around with legacy frameworks if they want to target phone, tablet, computer, watch, TV and glasses all with one codebase.
[1] https://swiftwithmajid.com
[2] https://twitter.com/InvadingOctopus/status/12792872846265794...
React Native is a pain to work with when the scope of your app becomes any larger than an agency level project (e.g. an app for an event that's only going to be used one weekend).
Once you start getting into requirements for a prime time production app (setting up APM tool, setting up tracking, setting up Google Analytics, native specific features that don't have a React Native hook yet) React Native is an extra layer of abstraction that slows you down. The experienced native developers hate working with it because they'd rather just use the related native platform themselves, but at the same time for any slightly complicated app you still need their expertise. Also, out of the box animations in React Native is difficult to work with, especially with less experienced developers, so you end up having to do a variety of work arounds to get animations between screens to look nice which you'd get out of the box just using Kotlin/Swift.
In 2020 if I needed to make an app quickly, cheaply, that worked on both platforms, I'd make a great mobile website and wrap it in a native shell. Any screen that needed a little bit extra "magic" I would do 100% native code for both platforms. This also allows you to ship updates to screens as you go without a complicated "codepush" JavaScript setup, as it's just a webview on the other end.
I'm still maintaining the React Native search app now, it works fine, but if we need to create an iOS version of it I'd definitely pitch doing it in native code.
Compared to SwiftUI it was far easier and even faster. Granted, I’ve worked with React a lot. But it’s really quite nice, I’m impressed with the whole ecosystem and how it’s grown.
I'm just starting to work on apps and I feel the same moral imperative, but have no special love for Xcode &co.
https://www.folklore.org/StoryView.py?story=Calculator_Const...
Hopefully they improved/will improve the docs.
For now it is possible to use standard API (C/C++, Posix, OpenGL, Vulkan)
But I have a bad feeling about this.
Meanwhile, the majority of the system remains based on C, C++, and Objective-C (accessible via C) APIs, the same that many of the other languages and frameworks tap into to access Apple's higher level frameworks.
Why the sudden fear and trepidation?
Let’s end the FUD.
Via the languages forced into game devs from platform SDKs.
C# and Java can be considered, at best, as branches in this evolution scheme.
C++ is by far the dominant language to create games today, and IMHO, for the foreseeable future.
Google tried to force every dev to use Java on Android for a while, but they finally and reluctantly added the NDK (C/C++) so that game devs would port their engines and games.
Oh the arguments how it was an heresy to even think contaminating the source code with C++ constructs.
Track down any C vs C++ flamewar on Usenet back in those days.
NDK exists since Android 2.0, hardly anything new, as is currently more castrated than on those days.
It is impossible to create a production level game engine in Android without reaching out to Java, given the API surface.
Game devs will use whatever the platform owner puts them on the table, when the platform is enticing enough to refuse being part of the party.
Just like if enough Indies make money with HTML 5 games, some bigger studios will eventually suck it up and use JavaScript, WebGL, and whatever tooling targets WebAssembly.
But many game devs have the privilege of not being motivated by money before everything else.
However, looking at the abysmal quality of apps they have been releasing on MacOS in the past few years, I wouldn't hold my breath.
In the past few years we've had anything from the new native AppStore that doesn't have a single consistent behaviour [1] to the plethora of half-baked barely functioning app stubs in Swift UI/Catalyst [2]. These are first-party apps by Apple themselves, and they are perfectly fine with the state they are in, and they had no qualms whatsoever when releasing them. That's what "obsessive attention to details"[3] has been on the Mac for the past many years.
The very few examples/exceptions (Big Sur's Messages) are exactly that: very few.
[1] https://grumpy.website/post/0RsaxCu3P and https://grumpy.website/post/0RsafwyK8 and https://grumpy.website/post/0SpwtkNB_
[2] Home, News, Podcasts, Developer App...
[3] That's from BigSur's marketing video
At the same time, they have been adding Mac features to iPadOS to make it easier to make a full-featured iPad app closer to a proper featured Mac app. One example there would be mouse/trackpad support. Another would be the multitasking support which, for all of its UX weaknesses on use, makes variable sized, multi window applications available on both platforms.
Messages is an example of the medium-term game Apple is playing here. I anticipate a large number of the built-in apps to be (finally) a single code-base under a single team. They are gaining more capability to do easy, deep customization per OS in each release - but also seeing the systems themselves move closer in terms of UX feature set.
Look and feel has little to do with the ability to run apps. The primary reason Apple Silicon will run iOS apps natively because it will be the same processor architecture.
However, a desktop OS being shoehorned into a mobile-like design is a very bad thing for a great amount of extremely obvious reasons.
Mac apps released by Apple have been a mishmash of very inconsistent design lately, most people in the Mac enthusiast community even agree with this (think Gruber, Marco, etc.)...
You're not talking about Big Sur, right? Because the contrast for that has gone waaay down for that in this release.
Mind, Mavericks is still a lot better than both...
It was like pulling teeth trying to convince developers to use Swift.
https://h4labs.wordpress.com/2016/02/09/should-i-use-objecti...
The “shiny new toy” argument doesn’t hold for long with Apple. You quickly get left behind in the Apple ecosystem if you don’t move with Apple.
While every language, environment, etc doesn’t need to move this fast, I personally prefer to jettison legacy sooner.
Huh? That was not what I witnessed at all. A lot of people were quick to adopt Swift when starting new projects, but still didn't replace Objective-C on the older ones. IMO it was one of the sanest language migrations I ever witnessed in this industry. (Java to Kotlin in Android also as nice and same, IMO)
Considering Apple still has a large Obj-C legacy, I doubt we'll see it deprecated any time soon. Carbon for example took almost 12 years to be removed!
The number of binaries and frameworks in iOS 14 using Objective-C vastly exceeds this relatively small list. Objective-C hasn't been jettisoned by Apple by any stretch of the imagination.
True, but melling didn't say that Objective-C has been jettisoned.
My understanding is that you can't iOS home screen widgets in Objective-C, correct? If so, isn't that a reasonably-clear signal that Objective-C developers are starting to be left behind?
I don't know, I haven't looked into them. But Swift is now more than 6 years old, and iOS home screen widgets are literally only days old, so I'd say "You quickly get left behind in the Apple ecosystem" is an exaggeration.
I did a lot of ObjC, but I've enjoyed using Swift. When I create frameworks and modules, they are Swift-only (no ObjC headers), because I like to leverage native Swift stuff, like enums and whatnot.
But I am writing app code. I think ObjC is a better systems language, so I don't think it's going anywhere, any time soon. It's a lot safer than "raw" C.
To me, Swift is a fairly high-level language, and I like that. I cut my teeth on the bare metal, and don't really miss working at that level.
My point was that Swift is better than pure Obj-C for systems programming. Admittedly, that might be a poor comparison, since Obj-C was specifically built to be used alongside C as the systems language.
But yes, I think the ultimate goal is that Swift will be better than C/C++ for systems programming too. It still has a ways to go, and there are a lot of libraries that will need to be written, but I do think it's possible.
https://www.objc.io/issues/18-games/metal/
C++ is used for Metal shaders.
I'm probably going to be all-in on SwiftUI but it does make me nervous -- what if Apple decides the bugginess level is acceptable and you should just code around it if you don't like it? That's a pretty terrible outcome for people like me who are investing now in the ecosystem.
Well, there are all kinds of apps written in SwiftUI.
It might not be ready to write Photoshop or Final Cut Pro in it, but most apps aren't "serious" like that. Heck, apps written in even less supported/mature environments (like React Native) will be just fine...
In what language do you think Metal and Core Audio are implemented?
Those went away along with DriverKit (and the performance issues for drivers due to Obj-C), when Apple created OS X.
Though DriverKit has been now re-used as a name, it's C++.
As for performance issues, that is the same talk about C devs regarding using C++ on kernel space, go figure.
> Metal is written in Objective-C, is based on Foundation, and makes use of Grand Central Dispatch to synchronize between the CPU and GPU.
https://www.objc.io/issues/18-games/metal/
> Shading Language: C++14, Runtime/API: Objective-C
I'm sure you can find 10 of such folks. I doubt you can find 50.
https://www.objc.io/issues/18-games/metal/
C++ is used for Metal shaders.
Most newcomers won't even know it exists.
For Swift it's a modern language that doesn't need to have backward compatibility with C that Objective-C had. It has a very expressive syntax and uses modern idioms you see in JS, Kotlin, Rust, Scala, C#, etc. It has a modern type system with type inference, string templating, Option type, tuples and simpler closures. It's pretty nice actually.
SwiftUI is just a way of writing UIs using Swift and a reactive paradigm. It looks and feels like React but instead of the embedded HTML of React it only uses plain Swift. The previous recommended method used XML (in XIB files) and needed special tooling (Interface Builder), which was nice but not perfect. Also doing git merges in the XML files are much harder.
That doesn't seem accurate. Interoperability with C and Objective-C was a fundamental design requirement of Swift. C interoperability is not particularly pleasant in Swift, but it's certainly there. It has to be there.
Apple has been creating some easier to use Swift wrappers around old UNIX C API. For example, their Network framework, and the just-announced Swift System.
Objective-C is a superset of C, so any valid C code is also valid Objective-C code, including all the pitfalls and footguns.
This is similar to the relationship between C and C++, however C++ isn't strictly a superset of C.
This phrase isn't entirely clear.
> Objective-C is a superset of C
This phrase is clearer.
In any case, I'm not fully convinced which language has the advantage and which the disadvantage in this case. You still have to call C API in Swift, and it's rather painful.
Perhaps the worst, "ugliest" feature of Swift is optionals. Why would you even add optionals to a new language if not for the necessity of Cocoa/ObjC compatibility. The language would be so much nicer without them.
And I completely disagree, they are one of the best features of any language and are able to remove a whole class of very annoying bugs.
And sorry, but I didn't understand the part about the initializer pattern... are you talking about constructor overloading? This has also been a traditional feature of OOP languages for decades.
The problem is that every Objective-C type is essentially an optional, so any Swift code using Cocoa frameworks, based on Objective-C, is a deluge of optionals. Your entire code base is constantly dealing with them. It's a mess.
> I didn't understand the part about the initializer pattern... are you talking about constructor overloading?
I'm talking about this: https://docs.swift.org/swift-book/LanguageGuide/Initializati...
Like I said, Optionals are an extremely popular feature in most modern languages, and Swift would be very criticized if it had not included it.
> I'm talking about this: https://docs.swift.org/swift-book/LanguageGuide/Initializati...
Ok, you are talking about constructor overloading, which is a pretty common and uncontroversial feature present in pretty much every OOP language made in the last 30-40 years.
No, I'm not. I'm talking about, for example, "Classes and structures must set all of their stored properties to an appropriate initial value by the time an instance of that class or structure is created." Which is not the case in Objective-C.
Also the concept of a "designated initializer", which is again simply a convention in ObjC.
EDIT: To be clear, I'm not trying to make statements about the history of programming languages, or about general programming concepts. I'm trying to say that the very specific way that Swift implements general programming concepts (which may vary greatly in different languages) was obviously inspired and constrained by backward compatibility with Cocoa and Objective-C. If you were to design a new programming language from scratch, without those backward compatibility requirements, you most likely wouldn't implement things exactly the way Swift does. It would be strange if you did. Swift is very much constrained by backward compatibility, and very much non-ideal as a result.
If you read that entire long initializer document from top to bottom, it's clear that this is all specifically based on Objective-C patterns — as it needs to be for Cocoa compatibility — regardless of whether there are historical antecedents of the general concept.
Sure, Swift has ObjC baggage, but those two specific features would be present in any multiparadigm language launched in the same period. Check out Scala, Kotlin and even C#, for example, and you'll see lots of similarities. Swift is going exacly where other languages are converging to.
In fact, the inspiration for the ad-hoc initializer pattern in ObjC you're mentioning probably came from other contemporary languages... maybe C++ or Smalltalk. Optionals in Swift have nothing to do with ObjC: in Swift they come from functional programming tradition, nullability in ObjC is a virtue of being a superset of C. The fact they work together is a virtue of compatibility, but those two Swift features were not specifically designed to serve ObjC.
Conceptually, the ability to represent the lack of a value is quite a common requirement. Swift has specific language syntax and compiler data structuring around the Optional type, but it is just a swift enumeration with an associated value at its core.
IUO (implicitly unwrapped optional) is mostly a compatibility feature however, for languages which were designed around the idea of nullable pointers like objc and C. UIKit and AppKit, for example, assume views have properties which can be nil before the view loads and non-nil afterward. IUO allows you to rely on this convention rather than have to safe or force-unwrap every property for use.
https://github.com/zhuowei/marina
The code itself is pretty easy to understand: https://github.com/zhuowei/marina/blob/master/marina_html.sw...
I think SwiftUI is still settling, so I expect to see more movement in this are in the short-term future. But I don't see Apple releasing an HTML-emitting-SwiftUI by themselves.
This isn't really true. Interface Builder was an alternative to writing UI code, but programmatic UI is still allowed and is well-supported. Many developers prefer it to IB.
Use IB to build small components and highest-level layouts.
Use code for everything in between, as well as individual views.
Yeah and that's exactly what I would call a disadvantage. I prefer dumb programming languages like Java, C++11 without the auto keyword, and Objective-C. They're much easier to understand because there are fewer ways to achieve the same thing and they don't require keeping as much context in your head while reading the code.
IRL example with Swift: I wanted to fix a logic bug in someone else's code and spent an hour trying to get a field from an object. I could see it in the debugger but every way to get it I could think of produced an uninformative syntax error. There was nothing to google because there were no keywords around it, even. Then the author of the code in question came online and explained that it's an "enum with associated value" (wtf?!) and you have to use this `if let` or `case let` abomination to extract the fields into local variables.
Another IRL example with Swift is that this whole immutability-by-default thing was just driving me insane because I'm too used to the fact that I can overwrite function/method arguments but Swift won't ever let me.
Associated values with enums are very powerful features of the language.
To me, it's all just abstractions that get in the way more than they help, tbh.
> I prefer C++11
C++ is like the prototypical example for "languages that require encyclopedic knowledge" so this seems like a weird comparison
To me it sounds as if your problem is purely lack of familiarity with modern languages, rather than them lacking some specific property that your usual languages have.
Swift is a very nice general purpose language and I’ve been writing code decades in almost most mainstream languages. I much prefer writing Swift code, in face some of my back end projects have been written in 100% swift, this allowed me to reuse models and APIs with the iOS and MacOS counterparts.
I'm asking because I like Obj-C/Swift, and am wondering if it's possible through some clang/LLVM magic to be able to code Obj-C/Swift in environments that expect C or C++, for example like in Qt. Like, could I have a traditionally C++ app (Qt app) but have most of my code be in another LLVM-compatible language.
It is possible! I mix Swift and Rust in my day job. I use the C ABI to interface between the two. The Swift layer is very thin and pretty much just a bridge between Rust and Cocoa/UIKit/Metal, but there's nothing stopping you from doing the opposite.
If you're going to bridge Swift with Qt, the sanest way is to use Objective-C++ to wrap Qt calls and call it from Swift.
However keep in mind that the Swift experience in other Operating Systems might not be as good as in Macs. That's why I went with Rust for this project. But things might have changed in the meantime!
I did some searching to see people's experiences substituting other languages for C++ through LLVM, and didn't find much other than samples of translated calls.
Given that there would be a big benefit to this (not having to learn a new language, less manual memory management), are there good reasons this isn't way more common?
If you use the C ABI you can just link a bunch of object files together.
Rust people are doing it a lot for graphics/game stuff, and there's lots of production MacOS apps mixing ObjC/Swift (because they're transitioning), or consuming C/C++. Of course in this case it's mostly Xcode doing the magic, but behind the scenes it's just calling clang.
That's still a massive language; the part you removed makes it basically be C++03 but even worse :/
auto something = someObject->someFunction();
// and then 10 lines of various operations on "something"
// also imagine that someObject is also auto and returned from somewhere
MyType something = new MyType(...);
Also, that code you mentioned seems like bad style with the auto keyword; the type should be obvious.
Do you have a better solution in mind?
There are many places where you see code without IDE-like features. One that comes to mind is everything related to git. Web-based git tools like github, git GUIs, command-line git, you name it.
Besides, it's nice to be able to read and understand the code without needing to download the entire project and importing it into an IDE just for that.
My idea is that you almost always write in an IDE, but not necessarily read in one. Thus, for verbose languages, the IDE would generate most of that example for you (I know for sure IDEA does this exact completion) but it will be perfectly understandable in a git diff.
Both git and web-based git+ services like Github are frequently used through deep editor/IDE integrations, so, no, I disagree that “everything related to git” is a good example here.
auto/var/val etc are best used when you can tell the type from the rvalue.
var m = new HashMap<String, List<Pair<X, Y>>>();
var m: Map<String, List<Pair<X, Y>>> = obj->someFunc();
I do. The problem is, others don't necessarily do. A good-in-my-world language makes it take more effort to write unreadable code than readable.
Everyone seems to only be judging languages by the code you write yourself, totally oblivious to the fact that reading and understanding someone else's code, including in projects you don't influence, is also an important part of being a software developer.
HashMap<Integer, ArrayList<String>> mapping = new HashMap<Integer, ArrayList<String>>();
Should we remove every feature that someone might misuse?
1. Modern language with conventions that will feel "normal" to ambitious younger programmers.
2. Lots of special language features to support the specific use-cases of iOS apps. As Go is to writing for server farms at Google, so is Swift to writing for Apple devices.
3. Very simple UI programming paradigm, at some point, maybe now? SwiftUI is or isn't production-ready depending whom you ask, but if we treat this as the future for iOS then it means any kind of data-centric or CRUD app will be trivial to bootstrap.
4. Sooner or later you will have no choice.
Granted, #4 is not an advantage to the language, but maybe to learning it?
Consider it's also possible to use other languages like JS/TS (via React Native, Phonegap, etc), Dart (via Flutter), C# (via Xamarin) or even Delphi (via Embarcadero RadStudio), among others, so even in the unlikely event of Apple deprecating Objective-C, choice is not really going away.