“column”

We've spent several days diagnosing a CoreData migration crash that is iOS 26-specific and reproducible 100% of the time. Posting here in case others have hit this and because we believe it's an Apple bug worth documenting. Upgrading from our App Store build (CoreData model v10) to our latest TestFlight build (model v11) crashes on iOS 26 with: NSCocoaErrorDomain / Code 134110 no such column: Z_110GROUPITEMS1 The same upgrade path on iOS 17 and iOS 18 works perfectly. What v10→v11 changes Two new entities added alphabetically early in the alphabet One new optional boolean attribute on an existing entity One new optional to-many relationship on the same existing entity All changes are lightweight-migration compatible. We use shouldMigrateStoreAutomatically = true and shouldInferMappingModelAutomatically = true Here's what we observed Adding two entities alphabetically shifts Z_ENT numbers for all subsequent entities. A central entity (EntityA) moves from Z_ENT 110 (v10) to Z_ENT 112 (v11). It has many

Condensed grid sections currently use a fixed two-column layout. On larger or higher-resolution head units, this underutilizes the available screen real estate. Is there support (or planned support) for adaptive breakpoints that expand to three or more columns on wider displays?

Hey everyone, hoping someone here has seen this before because I'm losing my mind. I uploaded my first TestFlight build yesterday and added two internal testers. Both of them accept the invite fine, but the moment they tap Install in the TestFlight app, they get: ▎ The requested app is not available or does not exist My developer account is about a month old, but yesterday was the first time I actually pushed a build to App Store Connect. I've spent the last several hours triple-checking every setting and as far as I can tell, everything looks right: Free Apps Agreement is Active under Business Price Schedule is set to USD 0 (Free) App is available in 175 countries Bundle ID matches between my project and App Store Connect Build metadata shows App Uses Non-Exempt Encryption: No (and the same key is in my Info.plist) The build status in my Internal Testing group Team is Testing with the green checkmark Both testers were added under Users and Access first, then to the internal group One tester shows Accepted st

Hi, can someone help me, I can not find any button to accept this license agreement. I am Account Holder, and after clicking to account link, it redirects to my developer account. I accepted it in my developer account, but when I come back to Apple Store Connect, this agreement is still there, and no accept button for me in Action column.

I'm building a document viewer on macOS Tahoe with a 3-column NSSplitViewController (sidebar | detail | inspector), trying to replicate how Preview displays PDFs with the page centered in the visible gap between the panels, with content bleeding under them when panning or zooming. I'm using the approach from Build an AppKit app with the new design (WWDC25): detailItem.automaticallyAdjustsSafeAreaInsets = true safeAreaInsets reports the correct values (e.g. left: 208, right: 240), and the frame does extend under both panels. But PDFView with autoScales = true anchors the page to the left edge of the window instead of centering it in the visible gap between the sidebar and inspector. I can get the page to center correctly by constraining PDFView to view.safeAreaLayoutGuide, but then content no longer extends under the panels when panning or zooming, which defeats the whole purpose. What's the correct way to center PDFView content within the visible gap while keeping the frame full-width so content blee

I have had this notice for a while: Registration is being processed for these devices. They may become available for development and ad hoc distribution in 24 to 72 hours. Changes to device availability will appear in the Status column. The status for my new iPhone has been stuck in this Processing state. See image:

I’m investigating Core Data lightweight migration behavior with SQLite and ran into a performance issue. Scenario: Model V1: EntityA has one fetchIndex Model V2: EntityA adds a new optional attribute timestamp (Integer 64), with no changes to existing attributes or fetchIndex definitions From a SQLite perspective, this change should be handled by a simple: ALTER TABLE ZENTITYA ADD COLUMN ZTIMESTAMP INTEGER But I observe that Core Data rebuilds the existing index, which becomes a significant performance issue for large databases. CoreData: sql: DROP INDEX IF EXISTS Z_EntityA_id CoreData: sql: ALTER TABLE ZENTITYA ADD COLUMN ZTIMESTAMP INTEGER CoreData: sql: CREATE INDEX IF NOT EXISTS Z_EntityA_byID ON ZENTITYA Question: Is there any way to avoid or bypass index rebuilding for this kind of schema changes?