Has anyone had success attempting to place a PKCanvasView in front of an image / UIImageView ?Setting the canvas backgroundColor to clear appears to work correctly, however when finger/pencil touches down the background of the PKCanvasView reverts to black 100% alpha.ThanksBen
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
My team recently released an app to the iOS app store. We are trying to add the Smart App Banner to our website to promote the app, but the banner is not shown. When the page loads, there is a flash of an empty Smart App Banner before it is automatically dismissed. This happens on every page load. If I put use an app ID of other apps the banner appears. I've triple checked that I'm using the correct app ID. So it seems like it is an issue with my app. I can see my app in the App Store, so I know it's available. I've tested on multiple phones.
1. System/device combinations where the issue does not occur:
Physical device: iOS 26.0 (23A5318c) + iPhone 16 Pro Max
2. System/device combinations where the issue does occur:
System versions:
Physical device: iOS 26.0 (23A5330a), iOS 26.0 (23A340)
Simulator: iOS 26.0 (23A339)
Device models:
Physical device: iPhone 12
Reproducible in Safari, WKWebView, and UIWebView:
Yes
Actual behavior
In WebView (and identically in Safari):
Before the keyboard is shown, header/footer elements with position: fixed are correctly aligned with the screen viewport. Scrolling up/down works as expected.
After the keyboard appears, the visualViewport position changes.
Bug: When the keyboard is dismissed, visualViewport.offsetTop does not reset to 0. As a result, fixed header/footer elements remain misaligned:
When scrolling down, the position looks correct.
When scrolling up, the header/footer are visibly offset.
Steps to reproduce
Focus an input field → the keyboard appears
Dismiss the keyboard
Observe that visualViewport.offsetTop remains >0 (does not reset to zero)
position: fixed header/footer elements are misplaced relative to the screen
Expected behavior
After the keyboard is dismissed, visualViewport.height should return to match the layout viewport, and visualViewport.offsetTop should reset to 0.
When scrolling upward, fixed elements should remain correctly positioned within the layout viewport.
Minimal reproducible demo
A simple HTML file containing:
A header and footer with position: fixed
An input element to trigger the keyboard
<!DOCTYPE html>
<html lang="zh-CN">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0, viewport-fit=cover" />
<title>H5 吸顶吸底页面 Demo</title>
<style>
* {
margin: 0;
padding: 0;
box-sizing: border-box;
}
body {
font-family: Arial, sans-serif;
height: 2000px; /* 设置内容高度 */
background-color: #f0f8ff; /* body 背景浅蓝色 */
padding-top: 120px; /* 预留 header 高度 */
padding-bottom: 60px; /* 预留 footer 高度 */
overflow-x: hidden;
}
/* 吸顶 Header */
header {
position: fixed;
top: 0;
left: 0;
width: 100%;
height: 120px;
background-color: #ff6b6b; /* 红色 */
display: flex;
align-items: center;
justify-content: center;
color: white;
font-size: 24px;
font-weight: bold;
z-index: 1000;
}
/* 吸底 Footer */
footer {
position: fixed;
bottom: 0;
left: 0;
width: 100%;
height: 60px;
background-color: #4ecdc4; /* 青绿色 */
display: flex;
align-items: center;
justify-content: center;
color: white;
font-size: 18px;
font-weight: bold;
z-index: 1000;
}
/* 输入框样式 */
.input-container {
margin: 100px auto;
width: 80%;
max-width: 600px;
text-align: center;
}
input[type='text'] {
padding: 12px;
font-size: 16px;
border: 2px solid #ddd;
border-radius: 8px;
width: 100%;
box-sizing: border-box;
}
input[type='text']:focus {
outline: none;
border-color: #4ecdc4;
}
</style>
</head>
<body>
<!-- 吸顶 Header -->
<header>吸顶 Header (120px)</header>
<!-- 主体内容 -->
<div class="input-container">
<input type="text" placeholder="请输入内容..." />
</div>
<!-- 吸底 Footer -->
<footer>吸底 Footer (60px)</footer>
</body>
</html>
On iOS 13 I used to use optional @State properties to adapt views. In my case, the presented view would either create a new object (an assignment) if the state that is passed into it is nil, or edit the assignment if an assignment was passed in. This would be done in the action block of a Button and it worked beautifully.
On iOS 14 / Xcode 12 this no longer seems to work. Given the following code which creates a new assignment and passes it into the editor view when the user taps a "New Assignment" button, the value of assignment remains nil. Is anyone else experiencing similar behaviour?
struct ContentView: View {
		@Environment(\.managedObjectContext) var context
		@State var assignmentEditorIsPresented = false
		@State var assignment: Assignment? = nil
		var Body: some View {
				[...]
				Button("New Assignment", action: {
						self.assignment = Assignment(context: context)
						self.assignmentEditorIsPresented = true
				})
				.sheet(isPresented: assignmentEditorIsPresented) {
						[...]
				}
		}
}
What's even weirder is that I tried adding a random piece of state, an Int, to this view and modifying it right before the assignment state (between lines 9 and 10) and it didn't change either.
In Xcode 14 RC, I'm seeing this in the Console:
[Assert] UINavigationBar decoded as unlocked for UINavigationController, or navigationBar delegate set up incorrectly. Inconsistent configuration may cause problems. navigationController=<MasterNavigationController: 0x135016200>, navigationBar=<UINavigationBar: 0x134f0aec0; frame = (0 20; 0 50); opaque = NO; autoresize = W; layer = <CALayer: 0x600000380be0>> delegate=0x135016200
The above message displays exactly four times immediately at app launch (top of the console) then does not repeat.
MasterNavigationController is the internal class for the app's navigation controller. It is in a Storyboard, with very minimal ObjC code. I am not setting any specific size for the nav bar.
I don't remember seeing this in earlier builds of Xcode, but I can't swear to it that this is new. No assertion actually fires.
Hi,
In my apps, the recent iOS 16.0 beta 7 (20A5356a) broke the .timer DateStyle property of the Text view, in a SwiftUI widget.
In previous OS and beta, Text(Date(), style: .timer) was correctly displaying an increasing counter.
In iOS 6.0 beta 7, Text(Date(), style: .timer) does not update anymore, (and is offset to the left).
The other DateStyle (like .offset, .relative, ...) seems to update correctly.
Anyone noticed that (very specific) problem ?
There are significant crash reports coming from iOS 18 users regarding AVKit framework that starts from this line [AVPlayerController _observeValueForKeyPath:oldValue:newValue:] which seems to be coming from iOS internal SDK. There are 2 kinds of crash we found:
UI modification on background thread
From the stack trace it seems like when AVPictureInPictureController is being deallocated and its view is being removed from superview somehow the code is being executed in background thread because there is this line there _AssertAutoLayoutOnAllowedThreadsOnly highlighted before the crash.
But I’ve checked our code that plays around AVPictureInPictureController, in the locations where we would deallocate the object it will always be called on main thread which are insideviewDidLoad and deinit inside UIViewController class. From the log, it seems like the crash happened when user try to open another content when PIP player is active resulting in the current PIP instance will be replaced with a new one. My suspect is the observation logic inside AVPlayerController could be the hint to this issue, probably something broken over there since this issue happened across our app versions on iOS 18 users only.
Unfortunately, I was unable to reproduce this issue yet but one of my colleagues reproduced it once but haven’t been able to do it again since. The reports keep raising each day up to 1.3k events in the last 30 days now.
Over release object
This one has lower reports than the first one but I decided to include it since it might have relevant information regarding the first crash since the starting stack trace is similar. The crash timing seems to be similar to the first one, where we deallocate existing AVPictureInPictureController and later replace it with a new one and also found only in iOS 18 users which also refers to [AVPlayerController _observeValueForKeyPath:oldValue:newValue:]. I also was unable to reproduce this issue so far.
Oh, and both of the issues happened on both iPhone and iPad.
We’d appreciate any advice on what we can do to avoid this in the future and probably any hint on why it could happened.
I have reported this issue with bug number: FB15620734
I also attached one sample crash report for each of the crashes here.
non ui thread access.crash
over release.crash
On iPads after updating to iPadOS 16.4, Safari often "looses" the session cookie provided by PlayFramework: When the browser requests assets (js scripts) or when additional data is fetched by JavaScript, the session cookie is not included in the request.
These secondary requests will redirect through our IAM because no session cookie is present. The IAM redirects back to the original domain with a payload so that the login session can be resumed. A new Set-Cookie header is sent in the response with the new session cookie.
This causes the framework to issue a new CSRF token (that is part of the session cookie) which is different from the old one that was already rendered into a hidden form input. The browser stores this new token and includes it when it POSTs the form. The token in the body of the request is now different from the one in the cookies, causing the CSRF check to fail.
We have tried different devices (Android, Windows, MacBook, and iPads) on different versions. The problem only occurs with Safari on iPad/MacBook running version 16.4, 16.4.1, or 16.5 beta. The problem cannot be reproduced using Chrome on iPad. Furthermore, the problem does not occur with private browsing in Safari.
Some things we ruled out:
Same behaviour on devices managed by MDM and on open devices.
PlayFramework version is now updated to the latest 2.8 version.
Using a separate cookie for the CSRF token (instead of the play session cookie) does not make a difference either.
Modifying the Cache-Control header to cache responses more aggressively or not at all does not help.
Has anyone also experienced this or similar problems?
I created a Radar for this FB14766095, but thought I would add it here for extra visibility, or if anyone else had any thoughts on the issue.
Basic Information
Please provide a descriptive title for your feedback:
iOS 18 hit testing functionality differs from iOS 17
What type of feedback are you reporting?
Incorrect/Unexpected Behavior
Description:
Please describe the issue and what steps we can take to reproduce it:
We have an issue in iOS 18 Beta 6 where hit testing functionality differs from the expected functionality in iOS 17.5.1 and previous versions of iOS.
iOS 17: When a sheet is presented, the hit-testing logic considers subviews of the root view, meaning the rootView itself is rarely the hit view.
iOS 18: When a sheet is presented, the hit-testing logic changes, sometimes considering the rootView itself as the hit view.
Code:
import SwiftUI
struct ContentView: View {
@State var isPresentingView: Bool = false
var body: some View {
VStack {
Text("View One")
Button {
isPresentingView.toggle()
} label: {
Text("Present View Two")
}
}
.padding()
.sheet(isPresented: $isPresentingView) {
ContentViewTwo()
}
}
}
#Preview {
ContentView()
}
struct ContentViewTwo: View {
@State var isPresentingView: Bool = false
var body: some View {
VStack {
Text("View Two")
}
.padding()
}
}
extension UIWindow {
public override func hitTest(_ point: CGPoint, with event: UIEvent?) -> UIView? {
/// Get view from superclass.
guard let hitView = super.hitTest(point, with: event) else { return nil }
print("RPTEST rootViewController = ", rootViewController.hashValue)
print("RPTEST rootViewController?.view = ", rootViewController?.view.hashValue)
print("RPTEST hitView = ", hitView.hashValue)
if let rootView = rootViewController?.view {
print("RPTEST rootViewController's view memory address: \(Unmanaged.passUnretained(rootView).toOpaque())")
print("RPTEST hitView memory address: \(Unmanaged.passUnretained(hitView).toOpaque())")
print("RPTEST Are they equal? \(rootView == hitView)")
}
/// If the returned view is the `UIHostingController`'s view, ignore.
print("MTEST: hitTest rootViewController?.view == hitView", rootViewController?.view == hitView)
print("MTEST: -")
return hitView
}
}
Looking at the print statements from the provided sample project:
iOS 17 presenting a sheet from a button tap on the ContentView():
RPTEST rootViewController's view memory address: 0x0000000120009200
RPTEST hitView memory address: 0x000000011fd25000
RPTEST Are they equal? false
MTEST: hitTest rootViewController?.view == hitView false
RPTEST rootViewController's view memory address: 0x0000000120009200
RPTEST hitView memory address: 0x000000011fd25000
RPTEST Are they equal? false
MTEST: hitTest rootViewController?.view == hitView false
iOS 17 dismiss from presented view:
RPTEST rootViewController's view memory address: 0x0000000120009200
RPTEST hitView memory address: 0x000000011fe04080
RPTEST Are they equal? false
MTEST: hitTest rootViewController?.view == hitView false
RPTEST rootViewController's view memory address: 0x0000000120009200
RPTEST hitView memory address: 0x000000011fe04080
RPTEST Are they equal? false
MTEST: hitTest rootViewController?.view == hitView false
iOS 18 presenting a sheet from a button tap on the ContentView():
RPTEST rootViewController's view memory address: 0x000000010333e3c0
RPTEST hitView memory address: 0x0000000103342080
RPTEST Are they equal? false
MTEST: hitTest rootViewController?.view == hitView false
RPTEST rootViewController's view memory address: 0x000000010333e3c0
RPTEST hitView memory address: 0x000000010333e3c0
RPTEST Are they equal? true
MTEST: hitTest rootViewController?.view == hitView true
You can see here ☝️ that in iOS 18 the views have the same memory address on the second call and are evaluated to be the same. This differs from iOS 17.
iOS 18 dismiss
RPTEST rootViewController's view memory address: 0x000000010333e3c0
RPTEST hitView memory address: 0x0000000103e80000
RPTEST Are they equal? false
MTEST: hitTest rootViewController?.view == hitView false
RPTEST rootViewController's view memory address: 0x000000010333e3c0
RPTEST hitView memory address: 0x0000000103e80000
RPTEST Are they equal? false
MTEST: hitTest rootViewController?.view == hitView false
The question I want to ask:
Is this an intended change, meaning the current functionality in iOS 18 is expected?
Or is this a bug and it's something that needs to be fixed?
As a user, I would expect that the hit testing functionality would remain the same from iOS 17 to iOS 18.
Thank you for your time.
On iOS17, UIDevice.current.batteryLevel is returning values rounded to 0.05, such as 1, 0.95, 0.9. Which used to be a 1% granularity in iOS16. Is this a bug or a new feature?
In previous versions of the simulator, it was possible to import files into the Files app by dragging them from the Finder into the Simulator. It appears that in the iOS 26 Simulator, this opens the file in Safari.
I've only tried it with .json files so far.
The documentation at https://developer.apple.com/documentation/xcode/sharing-data-with-simulator says that the original behaviour should happen:
To add files to Simulator, select one or more files in Finder on your Mac, then click the Share button. Select Simulator from the share destination list. Choose the simulated device from the drop-down list. Simulator opens the Files app, and lets you select where to save the files.
I'd love to learn if this is intentional behaviour, and if so, what workarounds there might be. I use this pattern quite a lot, as I have a HealthKit app, and I've built a system that allows me to export workouts as JSON files from a real device, that I can then import into a simulator for testing.
Edit: I found a workaround. Make a folder in Files.app, then search for it within ~/Library/Developer/CoreSimulator/Devices. Open the folder in Finder, then add any files you want to be available in the Simulator.
Hello!
I have experienced a weird bug in iOS 26 Beta (8) and previous beta versions. The safe area inset is not correctly aligned with the keyboard toolbar on real devices and simulators.
When you focus a new textfield the bottom safe area is correctly placed aligned the keyboard toolbar.
On real devices the safe area inset view is covered slightly by the keyboard toolbar, which is even worse than on the simulator.
Here's a clip from a simulator:
Here's the code that reproduced the bug I experienced in our app.
#Preview {
NavigationStack {
ScrollView {
TextField("", text: .constant(""))
.padding()
.background(Color.secondary)
TextField("", text: .constant(""))
.padding()
.background(Color.green)
}
.padding()
.safeAreaInset(edge: .bottom, content: {
Color.red
.frame(maxWidth: .infinity)
.frame(height: 40)
})
.toolbar {
ToolbarItem(placement: .keyboard) {
Button {} label: {
Text("test")
}
}
}
}
}
Hi,
I just migrated from Xcode 15 to Xcode 16.3 RC. When I run my app on any simulator, iOS 17 or iOS 18, I seeing strange behavior the second time I launch the app. The app uses a few frameworks, such as Firebase Crashlytics, and the network calls all work fine on the initial launch. however, subsequent launches consistently get the following error:
Task <17ACD3D4-FB31-4091-A797-D573F31909C2>.<2> finished with error [-1001] Error Domain=NSURLErrorDomain Code=-1001 "The request timed out." UserInfo={_kCFStreamErrorCodeKey=-2102, NSUnderlyingError=0x600000c46910 {Error Domain=kCFErrorDomainCFNetwork Code=-1001 "(null)" UserInfo={_kCFStreamErrorCodeKey=-2102, _kCFStreamErrorDomainKey=4}}, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <17ACD3D4-FB31-4091-A797-D573F31909C2>.<2>, _NSURLErrorRelatedURLSessionTaskErrorKey=(
"LocalDataTask <17ACD3D4-FB31-4091-A797-D573F31909C2>.<2>"
), NSLocalizedDescription=The request timed out.,
The only way to run again on that simulator is to Erase All Content and Settings. I did not see this issue in Xcode 16, and my app has been in production for over a year without networking issues.
Pushing to my phone works fine.
Running on MacBook Pro apple silicon - Sequoia 15.3.2
Any help would be greatly appreciated!
Thanks,
Mike
When trying to activate the VPN in the Settings menu of 18.4 beta (22E5200s) an error message pops up: ”The connection failed due to an irrecoverable error” The VPN works as expected with iOS and iPadOS 18.3.1 (22D72) and earlier releases.
Opening this question after discussing the issue in the AVCapture lab, hopefully so we can track down this issue.
We've been noticing some crashes in App Store Connect caused by layoutSublayers being called on a background thread.
After debugging the issue a bit we found that all calls which modified the AVCaptureSession or preview layer were indeed done on the main thread. It would be useful to see what results in AVCaptureVideoPreviewLayer.updateFormatDescription being called.
I've attached the crashlog below.
Crash log.ips - https://developer.apple.com/forums/content/attachment/800b0dba-3477-4c5a-b56c-f4cc393b384f
All of a sudden, after iOS 18.4 was released, I am having tons of navigation problems in my app in production. Buttons navigating to empty pages, views seeming to 'freeze', top navigation bar mismatched with the content of the page. It seems that iOS 18.4 broke a critical piece of UIKit + SwiftUI bridging functionality that my project relies on.
My application is written with both UIKit and SwiftUI components. Here is a breakdown of my setup:
UIApplicationDelegate >
UIWindow >
rootViewController of window is a UITabBarController >
each tab is a UINavigationController
rootViewController of nav controller is a UIHostingController >
rootView of the hosting controller is a SwiftUI View
In my SwiftUI views, I have been using NavigationLink for horizontal 'push' style navigation in my SwiftUI views. I do not use NavigationView, I only rely on the bridging capabilities of UINavigationController to action on my NavigationLinks. This has never been an issue, until iOS 18.4 was released. Now, when running iOS 18.4, I am having all sorts of unexpected behavior in the UI. I will break down 2 of these use cases here:
Use case A:
In one of my SwiftUI views, I have a ForEach for which each element's view is a NavigationLink. This is using the NavigationLink(_ destination:,label:) initializer. Navigating forward from here works/looks normal.
However, once I try to navigate backward from that destination (tap the 'Back' button in top left), the view goes blank and the navigation bar at the top of the page (which is maintained by the UINavigationController instance) does not change. If I call popToRootViewController on that nav controller, the navigation bar at the top of the page returns to its normal state, but the view is still blank.
It is not until after I have called popToRootViewController, and then navigate to a different tab of the UITabBarController and return to the initial tab, does the SwiftuI content view (the one with the ForEach) finally redraw and the view hierarchy is restored.
Here is a warning that is logged in the console when I tap the 'Back ' button:
Top view controller's view unexpectedly not in window for navigation transition. Skipping layout. nav = <UINavigationController: 0x1110bbe00>, topVC = <TtGC7SwiftUI19UIHostingControllerV5MyApp10MyPage: 0x106814e00>
EDIT: If I replace the NavigationLink with a call to UINavigationController.pushViewController, I am still seeing the exact same behavior. Pressing back button makes the view empty > need to pop to root view controller and switch tabs in order to restore the view.
Use case B
Another instance of this issue happens whenever I try to use a NavigationLink inside of a view that itself was the destination of a NavigationLink in its parent view (i.e.: Root view > detail view > sub-detail view). For example, take the detail view destination in use case A. I have tapped a NavigationLink from the ForEach and landed on the detail view. Again, so far things work/look normal. Now, if I tap on another NavigationLink from that detail view, the view does not transition to the new page. The top navigation bar does transition, and shows the title and actions associated with this second destination. However, the view of this second destination is not displayed.
It is worth noting that the same warning I mentioned above is also logged when I tap the NavigationLink to navigate to this second destination.
Top view controller's view unexpectedly not in window for navigation transition. Skipping layout. nav = <UINavigationController: 0x109859400>, topVC = <TtGC7SwiftUI19UIHostingControllerVVS_19BridgedPresentation8RootView: 0x300ab8000>
Strangely, if I switch to a different tab of the UITabBarController and back to the initial tab, this second destination's view is successfully rendered. It seems that switching tabs in this UITabBarController is calling something in either SwiftUI or UIKit that is redrawing my views.
Conclusion
This is a serious issue with UIKit + SwiftUI bridging support. I have never had problems like this until devices started running iOS 18.4, and there is nothing in the iOS 18.4 changelog that suggests this was an intentional change. All of a sudden, after updating to the latest iOS version, my app is totally broken.
I want to be clear that I'm not using deprecated NavigationLink methods in these instances. My app's minimum deployment target is iOS 16.
I know that there are more modern navigation APIs like navigation stack, etc. I am looking for answers about my use case: whether it is officially unsupported as of iOS 18.4, whether this setup should be supported and this is indeed some sort of bug in iOS, or anything in-between. I'm happy to provide formatted code if needed for discussion purposes. This is about my entire app's view hierarchy so there are a lot of disparate lines of code that make up this problem.
On iOS 18.0+ simulators, tap any share link button from any app, select "Save to Files", the "Save" button is disabled.
In all previous simulator versions this works. This behavior even happens with default Apple apps like Photos.
Simulator: Version 16.0 (1037)
XCode: Version 16.1 beta (16B5001e)
macOS: 14.6.1 (23G93)
We are experiencing a crash in our application that only occurs on devices running iOS beta 26. It looks like a Beta problem.
The crash appears to be caused by an excessive number of open File Descriptors.
We identified this after noticing a series of crashes in different parts of the code each time the app was launched. Sometimes it would crash right at the beginning, when trying to load the Firebase plist file.
That’s when we noticed a log message saying “too many open files,” and upon further investigation, we found that an excessive number of File Descriptors were open in our app, right after the didFinishLaunching method of the AppDelegate.
We used the native Darwin library to log information about the FDs and collected the following:
func logFDs() {
var rlim = rlimit()
if getrlimit(RLIMIT_NOFILE, &rlim) == 0 {
print("FD LIMIT: soft: \(rlim.rlim_cur), hard: \(rlim.rlim_max)")
}
// Count open FDs before Firebase
let openFDsBefore = countOpenFileDescriptors()
print("Open file descriptors BEFORE Firebase.configure(): \(openFDsBefore)")
}
private func countOpenFileDescriptors() -> Int {
var count = 0
let maxFD = getdtablesize()
for fd in 0..<maxFD {
if fcntl(fd, F_GETFD) != -1 {
count += 1
}
}
return count
}
With this code, we obtained the following data:
On a device with iOS 26 Beta 1, 2, or 3:
FD LIMIT: soft: 256, hard: 9223372036854775807
Open file descriptors BEFORE Firebase.configure(): 256
On a device with iOS 18:
FD LIMIT: soft: 256, hard: 9223372036854775807
Open file descriptors BEFORE Firebase.configure(): 57
In the case of the device running iOS 26 beta, the app crashes when executing Firebase.configure() because it cannot open the plist file, even though it can be found at the correct path — meaning the OS locates it.
To confirm this was indeed the issue, we used the following code to close FDs before proceeding with Firebase configuration. By placing a breakpoint just before Firebase.configure() and running the following LLDB command:
expr -l c -- for (int fd = 180; fd < 256; fd++) { (int)close(fd); }
This released the FDs, allowing Firebase to proceed with its configuration as expected. However, the app would later crash again after hitting the soft limit of file descriptors once more.
Digging deeper, we used this code to try to identify which FDs were being opened and causing the soft limit to be exceeded:
func checkFDPath() {
var r = rlimit()
if getrlimit(RLIMIT_NOFILE, &r) == 0 {
print("FD LIMIT: soft: \(r.rlim_cur), hard: \(r.rlim_max)")
for fd in 0..<Int32(r.rlim_cur) {
var path = [CChar](repeating: 0, count: Int(PATH_MAX))
if fcntl(fd, F_GETPATH, &path) != -1 {
print(String(cString: path))
}
}
}
}
We ran this command at the very beginning of the didFinishLaunching method in the AppDelegate.
On iOS 26, the log repeatedly showed Cryptexes creating a massive number of FDs, such as:
/dev/null
/dev/ttys000
/dev/ttys000
/private/var/mobile/Containers/Data/Application/AEE414F2-7D6F-44DF-A6D9-92EDD1D2B014/Library/Application Support/DTX_8.191.1.1003.sqlite
/private/var/mobile/Containers/Data/Application/AEE414F2-7D6F-44DF-A6D9-92EDD1D2B014/Library/Caches/KSCrash/MyAppScheme/Data/ConsoleLog.txt
/private/var/mobile/Containers/Data/Application/AEE414F2-7D6F-44DF-A6D9-92EDD1D2B014/Library/HTTPStorages/mybundleId/httpstorages.sqlite
/private/var/mobile/Containers/Data/Application/AEE414F2-7D6F-44DF-A6D9-92EDD1D2B014/Library/HTTPStorages/mybundleId/httpstorages.sqlite-wal
/private/var/mobile/Containers/Data/Application/AEE414F2-7D6F-44DF-A6D9-92EDD1D2B014/Library/HTTPStorages/mybundleId/httpstorages.sqlite-shm
/private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e
/private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.01
/private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.11
/private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.12
/private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.13
/private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.14
/private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.15
/private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.16
/private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.17
/private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.18
/private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.19
/private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.20
/private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.21
/private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.22
/private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.23
/private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.24
/private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.25
/private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.26
/private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.29
/private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.30
/private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.31
/private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.32
/private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.36
/private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.37
/private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.38
/private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.39
/private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.40
/private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e
…
This repeats itself a lot of times.
…
/private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.36
/private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.37
/private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.38
/private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.39
/private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.40
Basic Information
Please provide a descriptive title for your feedback:
Sheet presentationDetents breaks after rapid open/dismiss cycles
Which platform is most relevant for your report?
iOS
Description
Steps to Reproduce:
Create a sheet with presentationDetents([.medium])
Rapidly perform these actions multiple times (usually 3-4 times):
a. Open the sheet
b. Immediately scroll down to dismiss
Open the sheet again
Observe that the sheet now appears at .large size, ignoring the .medium detent
Expected Result:
Sheet should consistently maintain .medium size regardless of how quickly
it is opened and dismissed.
Actual Result:
After rapid open/dismiss cycles, the sheet ignores .medium detent and
appears at .large size.
Reproduction Rate:
Occurs consistently after 3-4 rapid open/dismiss cycles
More likely to occur with faster open/dismiss actions
Configuration:
iOS 18
Xcode 16.0 (16A242d)
SwiftUI
Device: iPhone 14
I've been seeing a high number of BGTaskScheduler related crashes, all of them coming from iOS 18.4. I've encountered this myself once on launch upon installing my app, but haven't been able to reproduce it since, even after doing multiple relaunches and reinstalls. Crash report attached at the bottom of this post.
I am not even able to symbolicate the reports despite having the archive on my MacBook:
Does anyone know if this is an iOS 18.4 bug or am I doing something wrong when scheduling the task? Below is my code for scheduling the background task on the view that appears when my app launches:
.onChange(of: scenePhase) { newPhase in
if newPhase == .active {
#if !os(macOS)
let request = BGAppRefreshTaskRequest(identifier: "notifications")
request.earliestBeginDate = Calendar.current.date(byAdding: .hour, value: 3, to: Date())
do {
try BGTaskScheduler.shared.submit(request)
Logger.notifications.log("Background task scheduled. Earliest begin date: \(request.earliestBeginDate?.description ?? "nil", privacy: .public)")
} catch let error {
// print("Scheduling Error \(error.localizedDescription)")
Logger.notifications.error("Error scheduling background task: \(error.localizedDescription, privacy: .public)")
}
#endif
...
}
2025-02-23_19-53-50.2294_+0000-876d2b8ec083447af883961da90398f00562f781.crash