Keith Harrison:
In iOS 18, SwiftData can make use of Foundation’s new #Expression macro to make it easier to build more complex predicates. From the WWDC session:
Expressions allow for reference values that do not produce true or false but instead allow for arbitrary types.
You can then evaluate the expression as part of more complex predicate.
[…]
If you expand the expression macro or check the Expression documentation you’ll see it’s creating PredicateExpressions which appear to support a wide range of methods. Unfortunately I can’t seem to get most of them to work either in predicates or expressions.
Previously:
Core Data iOS iOS 18 Mac macOS 15 Sequoia Programming SwiftData
Adam Engst:
Although the poll received relatively low participation because it was limited to TidBITS readers who own one of the iPhone 15 Pro models, the results still suggest that the Action button hasn’t been a runaway success. The most common use was to recreate the function of the Ring/Silent switch, garnering 33% of the votes. Even then, some people aren’t happy with the Action button as a replacement for the Ring/Silent switch because you can’t tell at a glance which state it’s in.
[…]
Another 21% of respondents use the Action button to open the Camera app, which I doubt iPhone 16 users will do, and 20% said they don’t use the Action button at all, like me. That’s a total of 74% who either use the Action button like the switch it replaces, don’t use it at all, or use it in a way that Apple is, in essence, deprecating in future iPhone models by adding the Camera Control.
I really like using the Action button to open the camera. It makes it fast and easy to take out my phone and snap a photo one-handed.
The more I learn about Camera Control, the less appealing it sounds. I think I would have rather seen a second regular button, so we would have both Action A and Action B, or perhaps one that was global and one for use within apps.
Juli Clover:
With the iPhone 16 lineup, Apple brought the Action Button to all four devices, expanding it from the Pro-only limitation last year. At the same time, there’s a new Camera Control button that eliminates the need to activate the camera with the Action Button, which was one of the major useful functions. At the same time, there are new Control Center options that you can set to the Action Button, expanding what’s possible.
I kind of wonder whether this is going to be another Touch Bar situation where the hardware’s full potential is never realized because Apple proscribes how it can be used without fully opening it up to third parties.
Previously:
Update (2024-10-01): Martin Pilkington:
I feel like I’d find more use for the action button on my iPhone if I could also assign actions for double click, triple click, long click, etc. Basically turns it into multiple buttons.
Camera iPhone 15 Pro iPhone 16 iPhone 16 Pro
Roderick E.J.H. Gadellaa (Hacker News):
As noted elsewhere, a developer-lamented but regulator-overlooked aspect of Apple’s monopoly on iOS browser engines has been the prevalence of show-stopping bugs.
We define “showstoppers” here as bugs that cause working apps to become entirely broken or inadvisable to use on the web.
All browsers have issues, but iOS is unique in depriving users of choices that developers can recommend when the system-provided engine breaks. Users and developers have literally no choice; they can’t choose a different browser to work around Apple’s frequent bouts of platform breakage. How bad is it? To get a sense for the impact, we’ve laid out the worst issues of the past decade. We’ve also included a rough estimate of the fraction of time when web apps would have worked as advertised on iOS but for Apple’s implementation… hiccups.
Via Alex Guyot:
These bugs heavily impact websites and web apps that are trying to build more sophisticated experiences on the web. They affect a wide variety of platform features which Apple itself claims to be stable and fully-supported. Safari is the only major browser that consistently ships bugs this nasty, and especially the only one that leaves them there for years.
[…]
The web isn’t an app store where you can list your site for only certain operating systems. People aren’t going to build ambitious PWAs when anyone who actually manages to install them on iOS is met with a broken experience.
I agree (and love it!) that Safari’s been improving on web standards recently, but this is also the year in which Apple almost killed PWAs with no notice, and has a bug in iOS 18 where keyboards don’t show up in PWAs in the EU.
Guillermo Rauch:
People often think native apps are better due to “performance of compiled code” but it’s actually due to “not a hostile, buggy, artificially API-poor environment”.
In the fullness of time, the web will win due to its superior deployment model and developer freedom. The days are long but the decades are short.
Joeri:
I was all-in on mobile web apps, but apple’s policy around iOS and browsers pretty much forced my hand. I had to watch how a native app team rewrote the web app I had already built, with the same feature set, except with notifications and more offline storage, crucial requirements at the time. This was over a decade ago, and while things have gotten a little better, the gap between what a web developer can do on iOS and what a native developer can do has never been wider.
scottjenson:
Too many don’t understand Apple’s privacy stance, which has some reasonable elements, is being used to massively foot drag on everyone else trying to build an open web ecosystem.
Previously:
Update (2024-10-01): Jeff Johnson:
Hanlon’s razor applies here. Apple is not deliberately trying to wreck web apps, any more than Apple is deliberately trying to wreck Safari extensions, or Safari itself, its user interface.
I think it’s probably neither malice nor stupidity. Apple just cares about different things so they have different priorities. That’s why it’s good for there to be a diversity of browser engines and for platform features like SMS auto-fill to not be restricted to Safari.
Update (2024-10-03): Uli Kusterer:
Safari is completely broken. No matter which page I visit, even just local HTML files, it goes “This web page was reloaded because a problem occurred”. Repeatedly.
Jeff Johnson:
It’s absurd that in the year 2024, Safari web extensions still don’t support match_about_blank.
This should have been a showstopping bug in 2020.
Update (2024-10-10): MurphysLaw:
So, I am currently in a Grad Program to get my teaching license and it is all online. I realized that Blackboard - the web software schools use to manage online classes - is not optimized for Safari only after the assignment was past due. It was running into errors that I did not even realize. My Grad School and the District that I work in both have this Frankenhybrid system of Google on top of Microsoft and as much as I hate to say it, the iPad without real Chrome is frustrating to use.
[…]
So either (A) Apple has to unleash Safari to make it worth web developers time or they (B) need to let real chrome on the iPad before anyone can consider it a “real” computer.
Update (2024-12-04): Christian Selig:
Does anyone find Safari on Sequoia will just randomly decide “Nah I don’t want to load any new pages for the next like… 30 seconds”? Other browsers will load things fine
Sebastiaan de With:
Yes! I thought it was just me. Sometimes just stops entirely. Reminds me of the old 10.5ish days where I’d use Safari every OS release til it stopped working an I had to switch to a usable browser :(
This has happened to me, too, and sometimes I need to restart the Mac in order for it to work. Waiting or quitting and relaunching Safari isn’t enough.
Update (2024-12-05): Sören:
Toggling all network interfaces (Ethernet, Wi-Fi) is enough IME
Bug History iOS Mac macOS 15 Sequoia Privacy Safari Web WebKit
Tim Hardwick:
The European Commission has initiated two specification proceedings to guide Apple towards compliance with its interoperability obligations under the DMA. These latest proceedings focus on iOS connectivity features for connected devices and the process Apple has established for addressing interoperability requests from developers.
[…]
The first proceeding targets iOS functionalities predominantly used by connected devices such as smartwatches, headphones, and virtual reality headsets. The EU intends to specify how Apple should provide effective interoperability with features like notifications, device pairing, and connectivity.
The second proceeding examines the transparency, timeliness, and fairness of Apple’s process for handling interoperability requests from developers and third parties for iOS and iPadOS.
Dan Moren:
The upshot seems to be to allow third-party accessories to have the same benefits as Apple’s own accessories, like the Apple Watch and AirPods. Some of this is work Apple’s already done with iOS 18’s new accessory pairing feature, which it’s now incumbent upon third-party developers to embrace. Ultimately, the experience for third-party accessories should be much closer to that of AirPods.
But at the end of the day, a lot of what makes AirPods better is the fact that it’s using Apple designed hardware, like the H-series chips instead of standard Bluetooth. I have difficulty imaging that the EC would require Apple to make that hardware available to third parties.
I don’t think that would make sense, but maybe they would try to require that iOS support software so that other companies could make AirPods competitors.
John Voorhees:
Apple prides itself on its tight integration between hardware and software, and the EC is determined to open that up for the benefit of all hardware manufacturers. While I think that is a good goal, we’re getting very close to the EU editing APIs, which I find hard to imagine will lead to an optimal outcome for Apple, third-party manufacturers, or consumers. However, if you accept the goal as worthwhile, it’s just as hard to imagine accomplishing it any other way given Apple’s apparent unwillingness to open iOS up itself.
Steve Troughton-Smith:
‘The DMA isn’t prescriptive enough!’
Careful what you wish for. 😏 If you can’t follow the spirit of the law, get ready for the detailed specifications.
John Gruber (Mastodon):
As ever with the Commission and their bureaucratese, I’m unsure whether this announcement is perfunctory or an escalation. But I think it’s an escalation, and they’re so irritated by Apple’s refusal to cave to the “spirit” of the DMA while complying with the letter of the law, that they’re simply going to tell Apple exactly what they want them to do in six months.
M.G. Siegler:
In other words, this feels a lot like one last push by Vestager to get Apple to comply with the continually vague “opening up” things they’re looking for – but really, it also feels like one last time in the spotlight and in the headlines for Vestager on this high-profile issue, as she has about a month remaining on her tenure.
Not only that, but it’s starting to sound like the EU is going to be taking a different approach to regulation – or at least looking at if they should – following Mario Draghi’s competition report, which was fairly damning of the ways the body currently operates and approaches regulation, among other things.
Previously:
Antitrust Digital Markets Act (DMA) European Union iOS iOS 18 Legal watchOS
