4,551 karma · joined September 23, 2012
Perhaps if they had opened parts of their infrastructure much earlier, they wouldn't be legally compelled to do it now, and have to invest significant resources to do so.
Hell, just releasing my own personal code as open source — auditing it, decoupling libraries, removing internal stuff, it's a huge multi-week effort for me to do. For any company with as much code as Apple, it's pretty daunting
For example, I don't think it would fly that they could say to the EU: users who want a third-party browser just have to enable root access and lose access to all Apple services and authentication
Apple has a significant engineering challenge to turn their current operating system into something that allows side-loading similar to what Google offers. It's not a matter of "commenting out an if statement"
The current developer SDKs Apple offers are strongly tied to their services, which cost them money to run. So first thing is, they have to decouple that so developers can implement applications using a baseline SDK that does not use Apple services (no iCloud, no Maps, no HealthKit and so on)
I think it would be great for users if they did do this. It would be akin to what Google does by shipping and updating Play Services separately from the base Android install
The reason I linked BrowserEngineKit is because if you want to do this properly, you have to build something like Apple has built with that framework (which was built to comply with these policies). Take for example, implementing your own JIT: because arm64e uses pointer authentication, the system uses PACs to ensure that pointers into executable code have not been tampered with. Apple now develops and supports a whole slew of APIs like `be_memory_inline_jit_restrict_rwx_to_rw_with_witness()` in order for developers to manage this themselves.
You saying "just let their pocket computers run software users download and install" is not like every single other computer ever made and sold. This is a gross oversimplification of the modern state of computing, both on mobile and on desktop. There are reasons you don't want random developers loading code into your OS kernel, and Windows and macOS both have protections for this (though the CrowdStrike crashes recently shows what happens when those protections are lax!)
If Apple wants to offer something similar, now, they are going to have a lot of work cut out for them.
You're not thinking this through, it's not a magic button Apple presses. They are going to have to develop a ton of frameworks just to get something like installable APKs.
Apple allows developers to use iCloud and Maps for free. Presumably because you distribute through the App Store. So if they allow for side-loading they're going to have to lock down and split their App Store "services" into a separate framework — hey, sounds familiar? Just like Google Play services.
Separating out all of Apple's authentication layers, paid and cloud services, and ensuring apps can be cleanly distributed without dependencies on those things it not a trivial engineering exercise.
I'm not trying to imply that Apple should not comply with the DMA. I believe they should. I also believe that it would be a seriously complicated thing to extract their App Store services from their developer APIs in such a way that people could develop against a baseline SDK sans Apple services.
You think side loading on Android cost Google "nothing" to implement and maintain? No, it costs them engineering resources to support that feature. It's a good feature to support and it's beneficial to users. But it's not free, it doesn't magically insert itself into the Android codebase if they "comment out an `if` statement" as the GP suggested.
Also, Android is gradually adopting many iOS-like permissions and security models. We recently updated our Android apps related to reading and writing to the file system. Why is that? Because the free-for-all they shipped with was heavily abused by developers.
https://developer.apple.com/documentation/browserenginekit
They needed to engineer, maintain, document and support a whole class of APIs so that third parties can create their own competitive browser engines (that offer JIT, etc) while still maintaining iOS sandbox security. There are going to be hundreds of frameworks, thousands of APIs, that will need to come to ensure compliance with the DMA
I have three notes that exhibit the bug you mention though: the three notes I keep for each of my children's artwork. I scan the artwork using the document scanning tool in Notes, and it gets embedded as a multi-page PDF (if the artwork itself has multiple parts) or a single PDF. After many years of adding high-res scans, when I scroll to the bottom of these files it takes some time for the note to render. I think I picked the wrong tool for the job here, more than anything!
Conversely, it's easier to debug an Objective-C app than a Swift app, simply because compiling and debugging is so much faster, and debugging so much more reliable
I don't know about a software quality drop being attributable to the migration to Swift. So many other things have also happened in that time — much more software that Apple produces is heavily reliant on network services, which they are not very good at. I find Apple's local-first software to be excellent (Final Cut Pro X, Logic, Keynote) and their network-first software is hit-or-miss
They have also saddled developers with a ton of APIs for working with their online services. Try to write correct and resilient application code that deals with files in iCloud? It's harder than it was to write an application that dealt with only local files a decade ago!
Swift is easy to blame, but I don't think it's responsible for poor software. Complexity is responsible for poor software, and we have so much more of that now days
I have published a word game written entirely in SwiftUI [1], the effects and animations would have been much more difficult to do in UIKit, and the app itself would have been hairier to write and maintain [2]. I also track crashes, and this particular app has had four crashes in the past year, so I am very pleased with the stability
That said, there are definitely times, as you say, where you have to drop to UIKit. For the word game mentioned above, I had to drop down to UIKit to observe low-level keyboard events in order to support hardware keyboard input without explicitly using a control that accepts text input
SwiftUI is mature, it's pretty advanced — especially for graphics and animation heavy UI. It has limitations, particularly around advanced input event handling, as well as the application/scene lifecycle
I plan to continue to use both UIKit and SwiftUI where they make sense. It's easy enough to bridge between them with UIHostingController and UIViewRepresentable
[2] Specific examples include: image and alpha masking is trivial in SwiftUI, Metal Shaders can be applied with a one-line modifier, gradients are easy and automatic, SwiftUI's Timeline+Canvas is very performant and more powerful than custom drawing with UIKit. Creating glows, textured text and images, blurs and geometry-based transitions is much easier in SwiftUI
But once we opened a Discord for our product we had so many more questions and users coming in. I do not like that it is locked up on a proprietary platform organised as a chat interface, but damn is it popular and often-used. Having users communicate with us more regularly is very motivating, and we've had so much more quality feedback by having it available
It is, unfortunately, where a lot of the people are and it makes your user base feel very "alive"
> What do I need to do? Designing the solution conceptually
> How am I going to do it? Actually writing the code
This article claims that LLMs accelerate the last step in the above process, but that is not how I have been using them.
Writing the code is not a huge time sink — and sometimes LLMs write it. But in my experience, LLMs have assisted partially with all three areas of development outlined in the article.
For me, I often dump a lot of context into Claude or ChatGPT and ask "what are some potential refactorings of this codebase if I want to add feature X + here are the requirements."
This leads to a back-and-forth session where I get some inspiration about possible ways to implement a large scale change to introduce a feature that may be tricky to fit into an existing architecture. The LLM here serves as a notepad or sketchbook of ideas, one that can quickly read existing API that I may have written a decade ago.
I also often use LLMs at the very start to identify problems and come up with feature ideas. Something like "I would really like to do X in my product, but here's a screenshot of my UI and I'm at a bit of a loss for how to do this without redesigning from scratch. Can you think of intuitive ways to integrate this? Or are there other things I am not thinking of that may solve the same problem."
The times when I get LLMs to write code are the times when the problem is tightly defined and it is an insular component. When I let LLMs introduce changes into an existing, complex system, no matter how much context I give, I always end up having to go in and fix things by hand (with the risk that something I don't understand slips through).
Good thread outlining the comparison
You can get a `utf8` or `utf16` "view" of a string, and index it like normal array (`myString.utf8[0]` gets the first utf8 character). But it's not going to work with complicated emoji, or different languages that may have representations into utf16, etc. Again, I think the vast majority of people don't care for complete correctness across all possible string representations, and possibly Swift has gone too far here — as noted by all the Stack Overflow posts and clunky API
On the array-pass-by-reference, I'd argue that it's valuable to learn those semantics and they aren't particularly complicated. They offer huge benefits relating to bugs caused by unintentionally shared state. Marking the parameter `inout` is a small price to pay, and really forces you to be explicit about your intentions
The default UITextInputStringTokenizer prefers to place the caret at word boundaries. I implemented exact placement for my coding app, Codea, and wrote about the text system extensively here: https://sim.coffee/textual-healing/
Exact caret placement is actually surprisingly effective with a reasonable font size. I wish Apple offered it as a preference system-wide
Selection defaults to a double-tap to select at the word granularity. Triple tap will select at the paragraph granularity. This is customisable in your own apps, though the system defaults to the one specific to your current language
I use it for work several times per week. I often want to test out some Swift API, or build something in SwiftUI, and for some reason it's way faster to tap it out on my iPad in Swift Playgrounds than to create a new project or playground in Xcode on my Mac — even when I'm sitting directly in front of my Mac
The iPad just doesn't have the clutter of windows and communication open like my mac does that makes it hard to focus on resolving one particular idea
I have so many playground files on my iPad, a quick glance at my project list: interactive gesture-driven animations, testing out time and date logic, rendering perceptual gradients, checking baseline alignment in SF Symbols, messing with NSFilePresenter, mocking out a UI design, animated text transitions, etc
In which case, it could be used as one of many signals in fingerprinting a device, as you could distinguish a returning user by checking their uptime against the time delta since the uptime at their last visit. It's not perfect, but when combined with other signals, might be helpful
Typing out comments on PRs, reproducing issues, modifying existing code to test hypotheses, discussing engineering options with colleagues, finding edge cases, helping QA other tickets, and so on. I guess this is all "thinking," too, but it often involves a keyboard, typing, and other people
A lower but still significant portion is "overhead." Switching branches, syncing branches, rebasing changes, fixing merge conflicts, setting up feature flags, fixing CI workflows, and so on
Depending on the size of the team, my gut feel for time consumption is:
Communication > Thinking > Writing Code > Overhead
I wonder, if you open up iOS, do you lose the privacy-protecting features? One of the benefits of iOS is that it makes good privacy decisions for you, where it can
If you take away the defaults, you kind of take away the design choices that were made to improve privacy. People (myself included) are not the best at making decisions that preserve their own privacy
Many people will hit whatever button gets them to the next stage of whatever it is they are trying to achieve. If Apple is not allowed to intervene in that experience, will we see a lot more people being taken advantage of by dark patterns and other software tricks?
Not only do they have two cameras per eye, and all the hardware for wide angle out-of-view hand tracking, they had to consider:
Privacy: the user’s gaze is never delivered to your process when your native UI reacts to their gaze. Building this infrastructure to be performant, bug free and secure is a lot of work. Not to mention making it completely transparent for developers to use
Design: they reconsidered every single iOS control in the context of gaze and pinch, and invented whole new UI paradigms that work really well with the existing SDK. You can insert 3D models into a SwiftUI scroll view, and scroll them, and it just works (they even fade at the cut off point)
Accessibility: there is a great deal of thought put into alternative navigation methods for users who cannot maintain consistent gaze
In addition to this they clearly thought about how to maintain “gazeable” targets in the UI. When you drag a window closer or farther it scales up and down maintaining exactly the same visual size, trying to ensure nothing gets too small or large to gaze at effectively
There are so many thousands of design and engineering decisions that went into making gaze and pinch based navigation work so simply, so I can understand how it hasn’t been done this effectively until now
The software was horrible:
* Highlight a search field, think you can use Alexa to dictate text? No, it'll just do a regular Alexa query. AppleTV gets this right: if you're on a text field, the mic button will just activate dictation to enter text
* Screensaver comes on, exit screensaver, also exits currently playing show back to the screen where you have to hit resume
* Slow, janky UI built with zero love
I felt bad when I eventually gave it away to my mum, who had a very early gen AppleTV that could not run Disney+. I felt so bad about inflicting the FireTV experience on her that I soon bought her a new AppleTV to replace it