Archive for June 2, 2023

Friday, June 2, 2023

WWDC 2023 Preview

Hartley Charlton:

Apple is overtly teasing the start of “a new era” and the ability to “code new worlds” at WWDC this year, building anticipation around the widely expected announcement of its mixed-reality headset.

Apple:

Activities are now open for sign-up for eligible developers. Designed to connect you with the developer community and Apple experts, they’ll feature Q&As, Meet the Presenters, and community icebreakers in online group chats.

Paul Hudson:

There are lots of events happening in and around Cupertino, along with other events happening around the world. Most in-person events require tickets, and are likely to sell out quickly.

Jordan Morgan:

Our favorite conference is here, which means that the ninth annual edition of the Swiftjective-C W.W.D.C. Pregame Quiz is ready to go!

MartianCraft:

Below, we share some of our talented staff’s thoughts about and predictions for WWDC and the transformative impact the forthcoming announcements might have on the industry.

Marco Arment:

Great things to do THIS week instead of next:

  • Prepare test devices with a test Apple ID to run the betas
  • Decide which devices will stay on iOS 16/watchOS 9/etc. (keeping in mind that Watches cannot downgrade!)
  • Start wearing your test watch to collect health data if applicable (thx @_Davidsmith)
  • Create a new version of your app in App Store Connect, and get its first build through TestFlight approval, so you can quickly issue another build next week if beta 1 breaks your app

Stephen Hackett:

Here are the rest of my picks on the show[…]

David Price:

Just like last year’s iPhone event, by an amazing coincidence, we’ve again stumbled across Tim Cook’s video script for Monday morning’s keynote presentation and of course, we’re going to share it all with you.

There are also a variety of books on sale, from:

See also: Who’s Going to WWDC23? and WWDC23 Keynote Bingo.

Previously:

A Vision for Using C++ From Swift

John McCall:

I’m pleased to announce that the Language Steering Group has accepted a vision document entitled Using C++ from Swift.

[…]

It is a companion to the previously-accepted vision document Using Swift from C++; together these two visions lay out a technical vision for how Swift can interoperate with C++.

Using C++ from Swift:

Swift’s memory safety is a major feature of its design, and C++’s lack of safety is a major defect. If C++’s unsafety is fully inherited when using C++ APIs from Swift, interoperability will have made Swift a worse language, and it will have undermined one of the reasons to migrate to Swift in the first place. But Swift must also make C++ APIs feel natural to use and fit into Swift’s strong language idioms. Often these goals coincide, because the better Swift understands how a C++ API is meant to be used, the more unsafety and boilerplate it can eliminate from use sites. If the Swift compiler does not understand how to import an API safely or idiomatically, it should decline to import it, requesting more information from the user (likely through the use of annotations) so that the API can be imported in a way that meets Swift’s standards.

[…]

Swift should recognize common C++ patterns like ranges (pairs of iterators) and containers and map them into Swift Collections, making them automatically work with Swift’s library of safe and idiomatic collections algorithms. For example, Swift code should be able to filter and map the contents of a std::vector[…]

[…]

There are three common patterns for managing reference object lifetimes in C++. Swift should endeavor to support all three of them[…]

[…]

Swift will need to decide how to handle projections, and more generally the use of view types, that it doesn’t recognize how to make safe. This may come with difficult trade-offs between usefulness and safety.

[…]

Generic code in Swift will not be able to use C++ templates generically without substantial new language features and a lot of implementation work. Allowing C++ templates to be used on concrete Swift types is theoretically more feasible but still a major project because of the ad hoc nature of type constraints in templates. If this feature is ever pursued, it will likely require substantial user guidance through annotations or wrappers around imported APIs.

Using Swift from C++:

For “reverse” interoperability, Swift generates a header that uses C++ language constructs to represent Swift APIs that are exposed by the Swift module. Because of the relatively high expressivity of C++ headers, the generated header is able to provide representation for most native Swift functions, methods, initializers, accessors and types without needing any extra code to be generated in the Swift module. This allows C++ programmers to call into Swift APIs using the familiar C++ function and member function call syntax.

[…]

Swift chose to require programs to opt in to Objective-C interoperability with the @objc attribute, both to make export more predictable and to avoid emitting extra code and metadata for all classes. In contrast, as long as the C++ compiler supports the Swift calling convention, a C++ header can call native Swift functions directly, and the C++ type system can be used to wrap most Swift types in a safe C++ representation. Because of this, there is no reason to require Swift module authors to opt in into C++ interoperability. Instead, any Swift module that can be imported into Swift can also be imported into C++, and most APIs will come across automatically.

Some API authors will desire explicit control over the C++ API. Swift will provide an annotation such as the proposed @expose attribute to allow precise control over which APIs get exposed to C++.

[…]

The existing Swift to Objective-C bridging layer should still be supported even when C++ bindings are generated in the generated header. Furthermore, the generated C++ bindings should use appropriate Objective-C++ types or constructs in the generated C++ declarations where it makes sense to do so. For instance, a Swift function that returns an Objective-C class instance should be usable from an Objective-C++ compilation unit.

Previously:

Update (2023-06-09): See also: C++ Interoperability in Swift 5.9.

Update (2023-07-26): See also: Mixing Swift and C++ (Hacker News).

Xcode 14.3.1

Apple:

The Xcode 14.3.1 release supports on-device debugging in iOS 11 and later, tvOS 11 and later, and watchOS 4 and later. Xcode 14.3.1 requires a Mac running macOS Ventura 13.0 or later.

[…]

Fixed: When targeting devices running iOS 13, apps built with Xcode 14.3 and using Objective-C protocols from Swift, sometimes crash at launch.

[…]

Fixed: Applications using Swift Concurrency could crash when run on a specific OS version

Xcode 14.3 was a buggy release. It’s not clear what’s changed in Xcode 14.3.1 since the unusual second release candidate, but judging from the sparse release notes most of the issues are still outstanding. Testing is still broken for me.

Previously:

Update (2023-06-15): Rory Prior:

Xcode 14.3 (and 14.3.1) really are a headache. Disappearing errors and random crashes on build are really driving me nuts. I wish they’d open source the editor, it’s been too buggy for too long now, clearly their internal priorities don’t match up somewhere as rather than each new version getting better it’s an absolute lottery whether any given Xcode version will be fit for purpose.

watchOS 9.5.1

Juli Clover:

Apple today released watchOS 9.5.1, a minor bug fix update designed for the Apple Watch.

[…]

According to Apple’s release notes for the update, it includes “improvements and bug fixes” for the Apple Watch, with no details on which bugs have been addressed.

Curiously, it’s not listed on the About watchOS 9 Updates page, and the security updates page says only that “the update has no published CVE entries.”

watchOS 9.5 came out at the same time as iOS 16.5 and macOS 13.4, and there have been no corresponding 0.0.1 updates for those operating systems.

Previously:

Copyright © 2000–2024 Michael Tsai.