Since iPadOS 26 we have been seeing a crash inside the system keyboard. It happens while the system keyboard renders key images. Our code is not on the crashing stack. Crash The app is terminated by an uncaught NSInvalidArgumentException. The NSXPC encoder fails to allocate a very large buffer while a keyboard image cache item is being encoded: NSInvalidArgumentException: *** NSAllocateMemoryPages(60003072) failedRequested sizes seen across reports: 60,003,072 / 60,558,656 / 78,724,160 / 240,001,920 / 933,149,952 bytes. Xcode Organizer groups these reports under the signature TextInput: -[TIImageCacheItem encodeWithCoder:] + 276. Relevant frames (main thread, simplified): objc_exception_throw NSAllocateMemoryPages NSXPCEncoder (encoding) -[TIImageCacheItem encodeWithCoder:] + 276 (TextInput) TIDispatchSync TIImageCacheClient UIKeyboardCache -[UIKBKeyView displayLayer:] ... UIApplicationMainScope (about 3 months of data) 327 crashes from 43 users. iPad only. iPadOS 26.1 – 26.7.1. No crashes on iPhone and none on iPadOS 18 or earlier. No single iPadOS 26 minor version stands out. The first occurrence did not line up with any release of our app. Our keyboard-related code did not change at that time. Free memory at crash time ranges from 33 MB to 4.8 GB. Some crashes happen within 40 seconds of launch. This looks like an abnormally large encode request, not memory pressure or a leak in the app. All affected users use the zh_CN locale. Context The screen has a plain UITextField, the standard system keyboard, and no custom inputView. It also has a UIIndirectScribbleInteraction for Apple Pencil handwriting. The crash happens shortly after the keyboard appears. Breadcrumbs show UICompatibilityInputViewController, UISystemInputAssistantViewController and UIPredictionViewController being set up just before the crash. Many crashes happen when the app window is not full screen (Split View / Stage Manager). For example, a 629.5 pt wide app window on a 1180 pt screen, or 936×954 on 1373×954. Some devices were rotating frequently. In a few cases there was a rapid burst of multi-tap gestures about 20 ms apart just before the crash (Pencil/Scribble-like input). What we tried We could not reproduce it on our own iPads running iPadOS 26. Memory stays flat and there is no crash. Questions Is this a known issue in the iPadOS 26 keyboard image cache (TIImageCacheItem)? Is there a recommended workaround on the app side, for example avoiding certain input view reloads or trait changes while the keyboard is visible?

Since iOS/iPadOS 27.0 (also macOS 27.0), saving a PDF with PDFDocument.dataRepresentation() (or write(to:)) writes every stream whose raw length is 0 as an empty indirect object: 6 0 obj endobjThat object is null, not a stream. When it is referenced from a page's /Contents array, Adobe Acrobat/Reader renders the whole page blank. Browser PDF viewers tolerate it, so the corruption is easy to miss. qpdf --check reports empty object treated as null and ignoring non-stream in an array of streams. No edits are needed to trigger it. Zero-length content streams are legal and fairly common; for example, PDFs generated by TallComponents PDFKit.NET contain a << /Filter /FlateDecode /Length 0 >> content stream on every page. In our case users sign such documents in an iPad app (custom PDFAnnotation) and we upload the result of dataRepresentation(); on iPadOS 27 every one of them opens blank in Acrobat. Minimal repro (builds a 1-page PDF whose /Contents is [text stream, zero-length stream], then re-serializes it): import PDFKit func minimalPDF() -> Data { let objects = [ "<< /Type /Catalog /Pages 2 0 R >>", "<< /Type /Pages /Kids [3 0 R] /Count 1 >>", "<< /Type /Page /Parent 2 0 R /MediaBox [0 0 595 842] /Resources << /Font << /F1 5 0 R >> >> /Contents [4 0 R 6 0 R] >>", "<< /Length 36 >>\nstream\nBT /F1 24 Tf 72 700 Td (Hello) Tj ET\nendstream", "<< /Type /Font /Subtype /Type1 /BaseFont /Helvetica >>", "<< /Length 0 >>\nstream\n\nendstream", // legal zero-length stream ] var pdf = "%PDF-1.7\n", offsets: [Int] = [] for (i, body) in objects.enumerated() { offsets.append(pdf.utf8.count) pdf += "\(i + 1) 0 obj\n\(body)\nendobj\n" } let xref = pdf.utf8.count pdf += "xref\n0 \(objects.count + 1)\n0000000000 65535 f \n" offsets.forEach { pdf += String(format: "%010d 00000 n \n", $0) } pdf += "trailer\n<< /Size \(objects.count + 1) /Root 1 0 R >>\nstartxref\n\(xref)\n%%EOF\n" return Data(pdf.utf8) } let saved = PDFDocument(data: minimalPDF())!.dataRepresentation()! print(String(decoding: saved, as: UTF8.self).contains("obj\nendobj") ? "BROKEN: null object written" : "OK")iOS 18.1: OK (PDFKit re-renders the page through Quartz). iOS 27.0 (24A5370g) / macOS 27.0 (26A428): BROKEN. With CG_PDF_VERBOSE=1 CoreGraphics logs writeStream: Failed to get data from stream. What triggers it: only the raw (encoded) length being 0. It happens with or without /Filter /FlateDecode, for a single /Contents stream, and for a zero-length Form XObject. A FlateDecode stream holding an 8-byte compressed empty payload (decoded length 0) is written correctly, so it is not about the decoded data. Where it seems to come from: iOS 27 introduced a structure-preserving serializer in CoreGraphics (CG::PDFDocumentSerializer). Its writeStream emits N 0 obj, asks for the stream's raw bytes, and when that returns NULL it logs the error above, skips the dictionary/stream/endstream, but still emits endobj. A legal empty stream returns NULL there, so it is treated as a read failure. Workaround we ship: after dataRepresentation(), find the empty objects (N G obj immediately followed by endobj) that are referenced from a page's /Contents, and append an incremental update that redefines them as << /Length 0 >>\nstream\n\nendstream, with a new xref section and a trailer whose /Prev points at the original startxref. The original bytes are untouched, so signatures/annotations written by PDFKit stay as they are, and files from iOS 18 (which contain no such objects) are returned unchanged. Filed as FB25282060. If you hit this too, please file a duplicate referencing that number. Possibly related iOS 27 save-path regressions: https://developer.apple.com/forums/thread/851708 (16-bpc annotation images truncated).

Since iOS/iPadOS 27.0, saving a PDF with PDFDocument.dataRepresentation() produces a corrupt file when a page contains a PDFAnnotation subclass that overrides draw(with:in:) and draws a 16-bits-per-component image. The same code works correctly on iOS 26.4. Filed as FBxxxxxxxx. What happens: The annotation is written with /AAPL:AKExtras, and its appearance (/AP) references an image XObject declared as /BitsPerComponent 16 (RGB). The image stream contains only half of the required data (8-bpc worth). Example: 1429 x 2021 image. Required: 17,328,054 bytes. Actual: 8,664,027 bytes. Adobe Acrobat reports "Insufficient data for an image". Other viewers read the 8-bpc data as 16-bpc, so the drawing is squeezed into the upper half of the page and the lower half is empty. In PDFKit, colors may turn black. The problem is in the writing step: a PDF written on iOS 27.0 is broken everywhere, while a PDF written on iOS 26.4 opens correctly on iOS 27.0. How to reproduce: Create a 16-bpc image with UIGraphicsImageRenderer (preferredRange = .extended, or the default format on a wide-color device). Add a PDFAnnotation subclass whose draw(with:in:) draws that image with context.draw(cgImage, in: bounds). Call dataRepresentation() and reopen the result. Current workaround: Create the image with an 8-bpc standard-range format before drawing it in the annotation: let format = UIGraphicsImageRendererFormat.preferred() format.preferredRange = .standard // 8 bpc, sRGB let renderer = UIGraphicsImageRenderer(size: size, format: format) With this, the declared bit depth and the data length match, and the PDF is valid on iOS 27.0. However, this gives up 16-bpc / wide-color output, so I would prefer a solution that keeps the original image quality. Possibly related: FB24882188 / FB24843022 (iOS 27 regression in PDFAnnotation subclasses that override draw(with:in:)). Questions: Does anyone know a way to avoid this issue without downgrading the image to 8 bpc? For example, a different way to create or attach the annotation appearance so that PDFKit on iOS 27 writes the 16-bpc data correctly. Has anyone else seen this, or confirmed whether it is fixed in a later iOS 27 release?

When you use .navigationTransition(.zoom(sourceID: "placeholder", in: placehoder)) for navigation animation, going back using the swipe gesture is still very buggy on IOS26. I know it has been mentioned in other places like here: https://developer.apple.com/forums/thread/796805?answerId=856846022#856846022 but nothing seems to have been done to fix this issue. Here is a video showing the bug comparing when the back button is used vs swipe to go back: https://imgur.com/a/JgEusRH I wish there was a way to at least disable the swipe back gesture until this bug is fixed.

I am having troubles with a .reality file in iPadOS 27.0.1. I have a Reality Composer Pro 3 project with an Animation Graph and Behavior Tree. The animation simply switches between a character walking and running, and the Behavior Tree simply changes the boolean to trigger the running state, waits, flips the boolean back, waits, and repeats. When I run the Simulate in RCP 3, it behaves as I expected - walks, runs, walks, runs, etc. I export the World scene as a .reality file, and open the .reality file in Xcode on macOS 27.2, and it behaves as I expected. But when I load the .reality file in an iPadOS app (iPadOS 27.0.1), the character does not switch between states. It starts the walking animation, but it never switches to the running animation. It appears the Behavior Tree isn't working as expected. Any idea what is wrong? Should I switch the iPad to the iPadOS 27 betas? Should I set the minimum OS target for the app to iPadOS 27? Is the Behavior Tree a known limitation with iOS or iPadOS 27?

Is there a public iPadOS API (or entitlement) that lets a third-party app present a transparent, interactive drawing layer over another foreground app? What I want: App A (Safari, a video app, etc.) stays in the foreground and remains visible. My app draws Apple Pencil ink on a transparent layer above that content. Pencil strokes go to my layer. I do not need to read the pixels underneath. This must be possible with public APIs only, for an App Store app. What I already checked, and why it does not match: UIWindow / windowLevel: only orders windows inside my own scene, not above another app. Slide Over, Split View, Stage Manager: a separate window beside or over the other app, not a transparent ink layer on its pixels. Picture in Picture with a custom content source: a floating window, not a full-screen transparent canvas. ReplayKit / ScreenCaptureKit: capture or broadcast, not an interactive overlay. Screen Time shields / AssistiveTouch-style overlays: system UI, not available to third-party apps. I am not asking for a review of an app concept. I am asking whether any current public API can do this, and if not, which of the options above is the supported boundary. Environment: iPadOS 26, Xcode 26, PencilKit.

We are seeing a crash when attempting to display the Japanese Kana keyboard (日本語－かな) in our iPhone-only app running on an iPad with iPadOS 27.0.1. The keyboard displays successfully in our app on iPadOS 26 and iPadOS 27.0. We also reproduced a similar crash in other iPhone-only apps downloaded from the App Store on the affected iPad. We have not yet confirmed whether those apps crash with the same exception. Our app logs the following exception: *** Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[__NSArrayM insertObject:atIndex:]: index 15 beyond bounds [0 .. 2]' *** First throw call stack: ( 0x19fab7190 0x19f834380 0x19fa45734 0x1aee9f5bc 0x1aee3dc14 0x1aee3cb30 0x1aee3c4d4 0x1aee3ab0c 0x1a433798c 0x1a44a4120 0x1a449bd5c 0x1a42148c8 0x1a42143fc 0x1a4239d7c 0x1a421203c 0x1a3fc1338 0x1a3d12e0c 0x1a3d11ed0 0x1a52784ec 0x1a3d11abc 0x1a4115238 0x1a3d436d4 0x1a3d43a80 0x1a44eea14 0x1aabb8ef8 0x1a517161c 0x1a5152450 0x1a5153388 0x1a41f20c4 0x1a49e3fec 0x1a426598c 0x1a42657fc 0x1a4265580 0x1a3d62b30 0x1a3d62984 0x1a95c4dac 0x1a994fb68 0x1a95c5514 0x1a95c287c 0x1a95d2608 0x1a3d6841c 0x1a3d6a298 0x1a4263874 0x1a3d60bdc 0x1a3ce8d78 0x1a3ce7b88 0x1a3ce7928 0x2d1482bc0 0x19fa78c20 0x19fa78b94 0x19fa5a268 0x19fa59384 0x19fa5a7f4 0x249e6ff24 0x1a3d381cc 0x1a9d27404 0x1a9d20b50 0x1a9d20a10 0x109042dc4 0x109042e04 0x19f8ab5b8 ) libc++abi: terminating due to uncaught exception of type NSException Steps to reproduce: Enable the Japanese – Kana keyboard in the iPad’s keyboard settings. Open an affected iPhone-only app on an iPad running iPadOS 27.0.1. Tap a text input field and attempt to display the Japanese Kana keyboard. The app crashes. We suspect this may be a regression involving iPhone compatibility mode on iPad and the Japanese Kana keyboard, but we have not yet identified the failing component in a symbolicated stack trace. We have submitted a report through Feedback Assistant: FB24985530. Has anyone else encountered this behavior? Are there any known workarounds we can apply in the app while this is being investigated?

I’m developing a SwiftUI iPad app that runs on an Apple silicon Mac as an iPad app—not as a Mac Catalyst app. The app supports multiple windows, with each Live Screen window associated with a different virtual machine. In the macOS Window menu, all child windows appear as “VirtualProg” rather than showing their content or VM name. The Live Screen window is created from a data-driven  WindowGroup , roughly like this: WindowGroup(id: "vm-screen", for: String.self) { $vmName in VMScreenWindow(vmName: vmName) .navigationTitle(vmName.map { "Live ($0)" } ?? "Live Screen") } I’ve tried setting the title with  .navigationTitle  both on the  WindowGroup  content and inside the window’s  NavigationStack . I also tried setting  windowScene.title  on the specific scene obtained from  view.window?.windowScene  after the view controller appeared. Neither changed the Window-menu entries. Is there a supported way to set a per-window title for the macOS Window menu when running an iPad app on Mac? Does  UIScene.title  affect that menu, or only the window title bar and app switcher? Is this a limitation of the iPad-app-on-Mac runtime, or is there a recommended SwiftUI/UIKit lifecycle hook for this? I’m looking for a public API solution rather than private AppKit/window introspection.

Hi, I'm curious if others have spent a long time stuck waiting for review. I submitted a week ago, and have a growing audience exited to play my new game and continuing to not have it available is hurting my growth. Should I submit a form for expedited review? Apple ID : 6816716633 Name: Atlas of Crowns Submission ID: 08837345-2546-48a8-a330-930d68dad2e0

The following question was asked in the Oct 13 iPhone Duo group lab: when you unfold iPhone Duo after you’ve scrolled down, does UIKit keep the position or should we re-anchor ourselves? The answer was various scroll views like collection views and text views will handle this for you to keep visible items visible, which also works when resizing the window on iPad. This is not working for me with a simple UICollectionView. What do I need to do to obtain this behavior? class ViewController: UIViewController, UICollectionViewDataSource { override func viewDidLoad() { super.viewDidLoad() let layout = UICollectionViewFlowLayout() layout.itemSize = CGSize(width: 80, height: 80) layout.minimumInteritemSpacing = 8 layout.minimumLineSpacing = 8 layout.sectionInsetReference = .fromLayoutMargins let collectionView = UICollectionView(frame: .zero, collectionViewLayout: layout) collectionView.translatesAutoresizingMaskIntoConstraints = false collectionView.backgroundColor = .systemBackground collectionView.dataSource = self collectionView.insetsLayoutMarginsFromSafeArea = true collectionView.register(UICollectionViewCell.self, forCellWithReuseIdentifier: "Cell") view.addSubview(collectionView) NSLayoutConstraint.activate([ collectionView.topAnchor.constraint(equalTo: view.topAnchor), collectionView.leadingAnchor.constraint(equalTo: view.leadingAnchor), collectionView.trailingAnchor.constraint(equalTo: view.trailingAnchor), collectionView.bottomAnchor.constraint(equalTo: view.bottomAnchor) ]) } func collectionView(_ collectionView: UICollectionView, numberOfItemsInSection section: Int) -> Int { 5000 } func collectionView(_ collectionView: UICollectionView, cellForItemAt indexPath: IndexPath) -> UICollectionViewCell { let cell = collectionView.dequeueReusableCell(withReuseIdentifier: "Cell", for: indexPath) var content = UIListContentConfiguration.cell() content.text = String(indexPath.item) content.textProperties.alignment = .center cell.contentConfiguration = content var background = UIBackgroundConfiguration.clear() background.backgroundColor = .secondarySystemBackground cell.backgroundConfiguration = background return cell } } Run the app on iPhone Duo Scroll down to cell 100 on the outer display Unfold the device Expected: It should stay scrolled to item 100 Actual: It scrolled down to item 225 (or more accurately, the content offset did not change, more content was added higher up with the contentSize shrinking due to the expanded width) In the past I've put so much work into trying to maintain the expected scroll position for orientation changes on iPhone and iPad/Mac Catalyst resize events, it's surprisingly incredibly hard to get working in every scenario, so I am SUPER interested to learn the system can do it for us!

I'm working on a navigation app. Since updating to iOS / iPadOS 27, several users have reported that location updates stop during navigation, or that the displayed location is far from where they actually are. Some users say the same thing happens in Apple Maps and Google Maps, so the cause seems to be in the OS rather than in any particular app's implementation. Reported symptoms The current location stops updating, or updates intermittently, during navigation The current location is shown far away from the user's actual position Reported devices and OS versions Almost all reports come from the iPad (9th generation), but the issue also occurs on iPhone. iPad (9th generation) Wi-Fi + Cellular / iPadOS 27.0 iPhone 16 Pro Max / iOS 27.0 iPhone 16 Pro / iOS 27.2 Public Beta iPhone 17 / iOS 27.0 Suggested workarounds (none resolved the issue) None of the following steps suggested to users helped: Checking location permissions ("While Using the App" or "Always", with "Precise Location" turned on) Turning Location Services off and on again Restarting the device Using "Reset Location & Privacy" Questions Has anyone else received similar reports on iOS / iPadOS 27? Any app-side workarounds would be greatly appreciated.

Hello, Since I upgraded my iPad (iPad Pro 11" 2nd generation / A12z) to iPadOS 27 I have the following issue with SwiftPlayground. The preview no longer works and gets stuck on "Preview paused / Restart to continue". If I click on the refresh button, the button becomes disabled a few seconds but preview still remains on "Preview paused". It is quite easy to reproduce : Start SwiftPlayground Click "New playground" Click "App" When "My App n" appears on playground browser click on it I already tried to uninstall / reinstall SwiftPlayground and rebooting my iPad but it didn't help. Thanks for any help

Hi everyone, I am experiencing a strange rendering issue on iPadOS 26 when sizeRestrictions.minimumSize is set on a UIWindowScene. After rotating the device and then rotating it back to the original orientation, the window appears to be stretched based on its previous dimensions. This resulting "stretched" area does not resize or redraw correctly, leaving a significant black region on the screen. Interestingly, as soon as I interact with the window (e.g., a slight drag or touch), the UI snaps back to its intended state and redraws perfectly. Here is a sample code and capture of behavior. class SceneDelegate: UIResponder, UIWindowSceneDelegate { var window: UIWindow? func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) { guard let windowScene = (scene as? UIWindowScene) else { return } windowScene.sizeRestrictions?.minimumSize = CGSize( width: 390, height: 844 // larger than the height of iPad in landscape ) // initialize... } } Has anyone else encountered this behavior? If so, are there any known workarounds to force a layout refresh or prevent this "ghost" black area during the rotation transition? Any insights would be greatly appreciated. Thanks!

I'm seeing a camera preview rotation issue on iPadOS 27 that depends only on the SDK the app is linked against. I've filed it as FB25106148 and wanted to share it in case others hit the same problem. Sample project: https://github.com/bc-lee/avfoundation-rotation-coordinator-discrete-resizing-poc Setup Portrait-only iPad app with UIRequiresFullScreen = YES Front camera AVCaptureVideoPreviewLayer, rotated with AVCaptureDevice.RotationCoordinator, as in the AVCam sample: let coordinator = AVCaptureDevice.RotationCoordinator(device: device, previewLayer: previewLayer) // On every change of videoRotationAngleForHorizonLevelPreview: previewLayer.connection?.videoRotationAngle = coordinator.videoRotationAngleForHorizonLevelPreview iPad Pro 11-inch (4th generation), iPadOS 27.0.1, Stage Manager on, Rotation Lock off What happens after rotating the iPad from portrait to landscape Xcode 26.5 (iOS 26.5 SDK) Xcode 27.1 RC (iOS 27.1 SDK) App UI Stays upright for the user, letterboxed Stays in portrait and lies on its side with the device (discrete resizing, TN3192) videoRotationAngleForHorizonLevelPreview 180° 180° Camera preview Upright Sideways The source code and Info.plist are the same for both builds. interfaceOrientation, effectiveGeometry, window and screen bounds, and isInterfaceOrientationLocked are also identical between the two builds, so I couldn't find a public value that tells the two presentations apart. In the iOS 27 SDK build, applying videoRotationAngleRelative(toDeviceOrientation:) (new in iOS 27) for the scene's interface orientation, which gives 90°, instead of the horizon-level preview angle restores an upright preview. Questions Is videoRotationAngleForHorizonLevelPreview expected to reflect the discrete resizing presentation in iPadOS 27? Until that is resolved, is using videoRotationAngleRelative(toDeviceOrientation:) with the scene's interface orientation, only when linked against the iOS 27 SDK and running on iOS 27, a reasonable workaround? Has anyone else seen this, or found a better approach?

Since iPadOS 27, Apple Pencil strokes that were drawn and saved through the system markup UI in QLPreviewController can no longer be erased with the pixel eraser once the PDF is saved and reopened. They can only be selected and deleted as whole annotations. On iPadOS 26 the same flow kept saved strokes erasable. Reproduction (no custom code needed — Files app shows it too): Files app → long-press a PDF → Quick Look → Markup Draw a few strokes with Apple Pencil, tap Done/save Reopen the same PDF in Quick Look → Markup Eraser (Erase Strokes mode) does nothing on the saved strokes The same happens in our app, which presents PDFs via QLPreviewController with editingModeFor = .createCopy. Newly drawn strokes in the current session erase fine; only saved-and-reloaded ones are affected. The new Preview app is NOT affected — the same PDF edited there stays fully re-editable. Digging into the saved files: Quick Look writes each stroke as a /Stamp annotation whose /AAPL:AKExtras contains only legacy AnnotationKit data (AKAnnotationObject with a flattened AKImageAnnotation, or AKAnnotationV2/AKInkAnnotation2) — and no /PPK entry. The Preview app embeds the PencilKit drawing data (/PPKType = "draw", /PPK with a "crdt" stream, plus page-level /AAPL:PPK + /AAPL:PPKHash), which is what makes its output re-editable. It looks like the iPadOS 27 markup editor only restores erasable strokes from /PPK, while the Quick Look save path still writes the old format — so Quick Look can no longer round-trip its own output. Questions: Is this an intentional behavior change or a regression? I couldn't find anything in the iPadOS 27 release notes about Quick Look / markup persistence. Is there any way for a host app to opt QLPreviewController's markup into the new PencilKit-based persistence?

I’m investigating an issue with simultaneous Apple Pencil and finger input on iPad. Apple Pencil + finger input works correctly while the Pencil user’s hand/palm is off the display. However, when drawing naturally with Apple Pencil with the palm resting on the display, an existing finger drawing contact elsewhere on the screen can be cancelled and then stop receiving input for several seconds. Pencil input continues normally throughout. Initially I suspected PencilKit, but I’ve reproduced the underlying behaviour below PencilKit/SwiftUI. Instrumenting UIKit at UIApplication.sendEvent shows the finger touch being cancelled and, in some cases, no further events for that finger for ~4–5 seconds while Pencil MOVED events continue to arrive normally. Everything delivered to the application is accounted for, so this appears to occur before our drawing/rendering code. Is this expected behaviour from the iPad’s Pencil/palm rejection? More specifically: Is there any supported way to tell UIKit that an existing finger contact should remain intentional while Pencil + palm contact is present? Is palm rejection configurable at this level? Is there another public input API we should be using for this scenario? We’re currently testing UIEvent.coalescedTouches(for:) to determine whether additional genuine finger samples are available during these apparent gaps, but haven’t completed that test yet. Any guidance on whether this interaction is expected to be supportable through public UIKit APIs would be appreciated.

I want to release an app under my company's name. From what I understand you need a DUNS number to verify your business. Because that takes about 30 days to be granted, I was thinking of releasing the app under my personal name and then moving it to the business account. Is that something I could do? Thanks

Hi, I have an univesal iOS app that supports multiple windows but i dont want the user to create the new window from WIndow top menu bar in iPad. I will create the windows from the main app using openWindow. Is there a way i can hide the New Window in the Window Menu top bar? Thanks in advance

The Problem When a user toggles radio buttons or checkboxes in a PDF using Preview, the widgets disappear following subsequent interactions after the file is saved and reopened. This renders the form fields unusable. Steps to Reproduce the Problem Open a PDF with radio buttons or checkboxes in Preview. Toggle a radio button or checkbox. Save and close the file. Re-open the PDF in Preview. Toggle the same button again. The button (and any others with the same field name) will disappear. Expected Results Toggling a radio button or checkbox should update the field value without causing the button (or related buttons) to disappear. This behavior is consistent with previous versions of PDFKit. What is Happening In Preview, interacting with radio buttons and checkboxes correctly updates their appearance as expected. Saving the PDF, however, causes the appearance dictionary to reference a new N entry that is a single appearance stream unassociated with any state. The annotation's AS entry is not updated. The original N entry remains but is no longer referenced. Subsequent interactions fail to update the visual presentation because the appearance stream is missing. Impact on User Experience Radio buttons and checkboxes may disappear and become unusable when toggled. PDF documents become irreparably altered after a button is toggled and the file is saved. PDF file size significantly increases when the file is saved. Users may believe they have successfully completed a form, only for the data to become inaccessible or invisible to recipients. Forms may need to be completely restarted or recreated from scratch if the original becomes unusable. The corrupted PDF structure might cause the file to render incorrectly or crash in third-party PDF viewers. Affected Apps/OSs Tested with Preview 11.0 (1147), as well as other apps that use PDFKit, on macOS Golden Gate 27.0 (26A428). This problem also affects PDFKit on iOS 27.0 and iPadOS 27.0. Feedback/bug report: FB24866826 Related Sample Output Original PDF File Checkbox widget annotation (6 0 obj), its appearance dictionary (17 0 obj), and normal appearance dictionary (18 0 obj). Button is not checked. 6 0 obj << /Border [ 0 0 0 ] /Rect [ 90 390 110 410 ] /T (button1) /F 4 /Subtype /Widget /DA (/.AppleSystemUIFont 13 Tf 0 g) /MK 16 0 R /C [ 0 ] /AP 17 0 R /V /Off /M (D:20260919225320Z00'00') /AS /Off /FT /Btn /Type /Annot /Ff 0 >> endobj 17 0 obj << /N 18 0 R >> endobj 18 0 obj << /Yes 20 0 R /Off 22 0 R >> endobj PDF File after Save Checkbox widget annotation object (6 0 obj), its new appearance dictionary object (8 0 obj), a new normal appearance stream object (20 0 obj), and the original appearance stream dictionary (now 21 0 obj). File saved after user checked button. 6 0 obj << /Ff 0 /Type /Annot /AS /Off /AP 8 0 R /MK 9 0 R /C [ 0 ] /FT /Btn /M (D:20260919225320Z00'00') /DA (/.AppleSystemUIFont 13 Tf 0 g) /Subtype /Widget /F 4 /Border [ 0 0 0 ] /Rect [ 90 390 110 410 ] /T (button1) /V (Yes) >> endobj 8 0 obj << /N 20 0 R >> endobj 20 0 obj << /Filter /FlateDecode /Resources << /ColorSpace << /CS1 [ /ICCBased 29 0 R ] /CS2 [ /ICCBased 30 0 R ] >> >> /BBox [ 0 0 20 20 ] /Type /XObject /Subtype /Form /Length 123 >> stream x UéA ¬0 Ô}≈|†≈nà¢úÛÇ* —SA =}Ïr(»ñµ≤w◊€YËà’|ÙÎŒç'óRï∂#SäÏÌü∞¢S‰Ì§ôRÌX }–É•åY Éçˆ BŒ H " *â´8™ˆZø6z⁄ÿ ”ú6ɀ੠"∫t˘‹;'¬ endstream endobj 21 0 obj << /Off 22 0 R /Yes 23 0 R >> endobj Note: No object references 21 0 obj in the PDF.

The Problem On opening a PDF document in the Preview app, PDF widget annotations appear pixelated/rasterized. This problem exists with button, text, and choice widget subtypes. The pixelation becomes more apparent when zoomed in. Expected Results PDF widgets should appear sharp and smooth, without pixelation. In previous versions of the Preview app, widgets appear vector-based as expected. Impact on User Experience PDF widgets appear pixelated and inconsistent with text content in the same PDF document. Widgets do not look like elements of an interactive form but, instead, resemble low-quality embedded images. Affected Apps/OSs: Preview 11.0 (1147), as well as other apps that use PDFKit, on macOS Golden Gate 27.0 (26A428). A similar problem appears to affect PDFKit on iOS 27.0 and iPadOS 27.0 as well. Feedback/bug report: FB24843022