Ever since the iPhone X, upside-down orientation on the iPhone has been disabled by design. I haven't found any official documentation explaining why, but my guess is it has to do with Face ID and the top notch. However, now that the iPhone Duo has no Face ID or notch—and includes reserved occlusion regions—why not enable upside-down rotation? As of iOS 27.1, it remains disabled. Leaving it turned off only confuses users, making them think their favorite apps are frozen when they won't rotate.

I took a screenshot of the Safety Area's and Occlusions on the iPhone Duo outer display. The article Designing for iPhone Duo tells us to... Consider using the full display width for interfaces where bars aren’t necessary. Some layouts can span the full display, which works well for visual, immersive interfaces that don’t scroll, as long as nothing conflicts with the Dynamic Island or the status bar. Calculator, for example, occupies the full width of the display. You can also combine both approaches, letting a background image or header span the full width while scrollable content stays inset. The Graphics Content can easily take up the full space which can be achieved by ignoring the safe area (.ignoresSafeArea()). And knowing the iPhone Duo there is no occlusion so I can also ignore the safe area for the interactable content. However we now are entering an awkward state. Because now I need to make decisions based on a specific device. Knowing the iPhone Duo I can ignore horizontal safe area and expand to full width because there is no occlusions here, but ignoring the safe-area may result in unexpected behavior on other (future) devices which then requires me to use code that specificly targets certain devices. I wished SwiftUI had something that I could safely expand the interactable content the full width.

In the article Designing for iPhone Duo there is a section: Consider using the full display width for interfaces where bars aren’t necessary. Some layouts can span the full display, which works well for visual, immersive interfaces that don’t scroll, as long as nothing conflicts with the Dynamic Island or the status bar. Calculator, for example, occupies the full width of the display. You can also combine both approaches, letting a background image or header span the full width while scrollable content stays inset. However, in order to do this, you need to ignore the safe area. This feels more like designing for a posture than designing declaratively. I want to use the full width on the iPhone Duo because I don't have any toolbars or tab bars and a symmetrical layout makes more sense. However the content is important, and if a new device comes out that might use the safe area, my full-width app might not be functional any longer. What I would like is to keep using the safe area, but somehow tell it that I want a full display width while respecting a safe area that might block my content in the future.

In the video Design for iPhone Duo, near the end (10:00), they demonstrate what the UI could look like in multiple poses. Naturally, it feels intuitive to place the presentation view in the primary view and the controls in the secondary view. This way, when split horizontally, the controls are right under your fingertips, and when split vertically, they rest on the flat surface. While this works well, the secondary view is hidden in the compact x compact landscape layout, whereas it remains visible in compact x compact portrait. This seems like an odd choice, especially when looking at the UI shown in the video during the tent pose. Here you can clearly see the presentation on the left and the controls on the right. So why hide it? Apple when you are reading along, please just split when I ask it to split horizontally.

So I downloaded and installed iOS26 on my iPhone 15 Pro and after that it does not want to boot anymore. It shows a battery with one red line. Which is weird because before it restarted it had 80% of the battery and I had the power cable connected at all time. Now I can't boot it up anymore. Not even with the volume button up, down, power button trick. Please help!

So it seems the NetworkFramework is still not able to support Broastcast Mode am I correct? As soon as I switch broadcast mode to On in my game I receive console messages instead of receiving data. nw_path_evaluator_create_flow_inner failed NECP_CLIENT_ACTION_ADD_FLOW (null) evaluator parameters: udp, definite, server, attribution: developer, reuse local address, context: Default Network Context (private), proc: 2702288D-96FB-37DD-8610-A68CC526EA0F, local address: 0.0.0.0:20778 nw_path_evaluator_create_flow_inner NECP_CLIENT_ACTION_ADD_FLOW 1FB68D7E-7C9B-47B2-B6AC-E5710CD9C9CD [17: File exists] nw_endpoint_flow_setup_channel [C2 192.168.178.221:52716 initial channel-flow (satisfied (Path is satisfied), interface: en0[802.11], ipv4, ipv6, dns, uses wifi)] failed to request add nexus flow nw_endpoint_flow_failed_with_error [C2 192.168.178.221:52716 initial channel-flow (satisfied (Path is satisfied), interface: en0[802.11], ipv4, ipv6, dns, uses wifi)] already failing, returning nw_endpoint_handler_create_from_protocol_listener [C2 192.168.178.221:52716 failed channel-flow (satisfied (Path is satisfied), interface: en0[802.11], ipv4, ipv6, dns, uses wifi)] nw_endpoint_flow_pre_attach_protocols nw_connection_create_from_protocol_on_nw_queue [C2] Failed to create connection from listener nw_ip_channel_inbox_handle_new_flow nw_connection_create_from_protocol_on_nw_queue failed I won't be able to receive data which is a real shame, so I guess I am stuck with the lower level code: // Enable broadcast var enableBroadcast: Int32 = 1 if setsockopt(socketDescriptor, SOL_SOCKET, SO_BROADCAST, &enableBroadcast, socklen_t(MemoryLayout<Int32>.size)) == -1 { let errorMessage = String(cString: strerror(errno)) throw UDPSocketError.cannotEnableBroadcast(errorMessage) }

let localhost: NWEndpoint.Host = NWEndpoint.Host("127.0.0.1") let port: NWEndpoint.Port = NWEndpoint.Port(integerLiteral: 555) do { let multicast = try NWMulticastGroup(for: [.hostPort(host: localhost, port: port)]) print(multicast) } catch { print(error) return } Returns the error POSIXErrorCode(rawValue: 22): Invalid argument. Running on macOS. (Follow up question, does only receiving multicast also require entitlements for iOS?) How can I make NWMulticastGroup work?

Hear me out, developers at Apple! You've done an amazing job with privacy so far. The introduction of ContactAccess and the Contact Access Button this year is truly an amazing work of art. Well done. However, all the way back to the first iPhone I got in 2007, I wished Apple would make API's available to access the users installed apps (in a privacy way). This would (further) open up apps in the category of App Managers and App Launchers. Back in the early days the trick was to use deep link, but that was also awkward, since you needed to know the deeplink upfront and the apps needed to support it. Not ideal. It also had a side effect that Apple noticed, that evil party's used it to scan your device to know which apps you had installed and create a profile from that. Apple fixed that by using LSApplicationQueriesSchemes. Now you have to tell the App upfront which apps you will be calling (up to 50), or use Universal Link to be freed from this limitation again. Again not ideal. Why not turn it around and let the user decide? User central. Imagine an App Launcher app. There is a button in the launcher app where you as a user can click on to add an app. It calls an api available from Apple to launch a privacy shielded sheet with the apps the user got installed on its device. These are not exposed to the launcher app. When the user clicks on the installed app (or apps) it likes to add, the launcher app will get identifiers to launch the app. That's it. This would be limited access, perhaps the api could also expose full access, so permission could be granted once and the app will get all identifiers available. The choice will be up to the user. One step further, but this would be more nice-to-have, is the ability to access meta data of the app, such as icon, title, last launched, app size, etc. This way App Launchers can make decisions such as putting the most recent launched app in front or App Managers can use this to decide which apps you are not using and can advise to remove them to clean up space. Love to hear everyone's opinion. So let it be the start of the discussion.