interpol_p

That is an oversimplification of what I stated.

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!)

Google engineered and maintains the system that allows you to install APK files. This is my point. The fact that they have developed a security model around APK updates is exactly what I'm talking about.

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 missed my point. My point is that if Apple wants to add this now, it's going to cost them engineering resources.

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.

It’s extremely complex. I’m not debating whether they should comply - they should. But it’s gonna cost them years of engineering effort, and maintenance far into the future. See, for example, BrowserEngineKit

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 wouldn't say it's "damn buggy" — I use Notes daily, and have a significant number of notes that are synced between devices. In my notes I use rich formatting, embed videos, voice memos and lots of images. It handles it really well. I even use iCloud Collaboration feature on a few notes for planning, and for splitting regular expenses

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!

Thanks for the suggestion! I had no idea this existed

It's easier to read and navigate a well-written Swift codebase than a well-written Objective-C codebase

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 don't completely agree with you. Having used both SwiftUI and UIKit extensively, I value both of them and think they are both quite strong in different areas

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

[1] https://retrogram.app

[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

Totally agree

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"

> Why am I doing this? Understanding the business problem and value

> 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).

When wiring up my projector, I needed a 10 or 20 meter HDMI cable. The first one I got produced a snowy image on the screen — it wasn't like analogue static, but it was definitely a poor quality image. I replaced that cable with a more expensive one and the image looked correct. It surprised me that there would be a difference in HDMI cables, because I thought exactly the same way — a digital signal is a digital signal

Doh, sorry:

https://mastodon.social/@stroughtonsmith/113641024185902808

In this case I think they are missing a lot of deserved credit. A ton of UI paradigms, established by visionOS, are taken wholesale in XR. Even down to the styling of the developer docs

Good thread outlining the comparison

https://mastodon.social/@stroughtonsmith/11364102418590280

Anyone know how well / if this compares with BGFX?

https://github.com/bkaradzic/bgfx

There is a modification to this design that adds a button to the top to pop out the phone: https://www.yankodesign.com/2024/09/13/dieter-rams-inspired-...

Three of those really are very specific to string manipulation, and doing it "right" (with all the possible representations of what a string can be) is inherently complex. I think Swift landed on the wrong side of defaults for this API, opting for "completely safe and correct" over "defaults to doing what I expect 99% of the time"

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

At this point I can only guess that it's an explicit decision by Facebook not to support iPad — that is, they have some reason for wanting their user base to preference their interactions with the app using their phones

Thank you! We build Codea in our spare time, evenings and on weekends. It’s a really rewarding project

It’s not arbitrary, it’s intentional (though you and I may hate it)

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

You're probably correct about it being hard to make a decent iOS app in Swift Playgrounds, but it's definitely not a toy

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

My understanding is this gets something like the system uptime? (I may be reading the docs wrong).

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

In my experience quite a lot of programming is thinking, though quite a lot is also communication, if you work in a team

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

The pay listed in that comment doesn’t seem particularly outrageous for C-level execs in an organization, even a non-profit

This happened in my family. Except my cousins just banded together and bought our Android using family member an iPhone. She was pleased with the result

> 1. One OS is locked down, has a walled-garden ecosystem, but has many privacy-protecting features.

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?

Putting it together is not as simple as it seems. I think it was an immense engineering and design effort from Apple to get it to the point where it feels effortless and obvious

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

I bought a FireTV stick for the lesser-used TV, having been accustomed to the Apple TV in the main room. It was cheap, and seemed to do all the stuff

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

I think the DMA mandates that Apple not give Safari advantages over other browsers. Being able to run PWAs seems like it could be considered an advantage? Not sure though

They are not allowed to give their browser an advantage under the DMA. If you take a look at BrowserEngineKit and BrowserKit there is a significant API surface area they offer for third-party browser engines. They must have been building this for some time. It's really detailed, down to allowing developers to implement their own JIT! [1] they have custom UI components replacing their standard scroll views with ones that better support nested scrollable DOM elements. It's a staggering amount of engineering effort

I can totally believe that there is not enough time to re-think and re-architect how to implement push notifications, local storage and whatever other perks PWAs get for non-Safari third-party browser engines running as "apps." They may have lots of money and engineers, but throwing more of them at this problem is not going to build a well designed, thoroughly tested, and secure implementation any faster

[1]: https://developer.apple.com/documentation/browserenginekit/p...

It's pretty well hidden to the point of "why do they bother supporting this feature?"