Posts

Post not yet marked as solved
2 Replies
542 Views
I'm having trouble with XCode Simulator and device rotation using SwiftUI app. (Simulator Version 14.3.1 (994) SimulatorKit 629 CoreSimulator 885.2) The horizontalSizeClass/verticalSizeClass as reported by simulator does not match the sizes given in https://developer.apple.com/design/human-interface-guidelines/layout when rotating the device. It is correct on initial start, but on first device rotation (say e.g. portrait to landscape orientation) the values remain the same, despite monitoring with .onChange suggesting that they have changed! Then it appears to lag one device rotation behind the actual orientation for subsequent rotations. Such that on second device rotation (say landscape back to portrait) the values change to those associated with landscape instead of portrait - and so on for all subsequent rotations. It's a particular issue with "large" iPhones when simulator gives width = .compact and height = .regular in landscape orentation when it should be the other way round! Any insights from anyone as what is going on? Is it a bug or am I doing something wrong? Thanks
Posted
by DCS17.
Last updated
.
Post not yet marked as solved
2 Replies
974 Views
Hi, I have a CoreData based app using NSPersistenCloudKitContainer with SwiftUI. Works fine with small datasets. However there are images stored as BLOBs which increases the size significantly eventually. The problem is that force checkpointing fails to reliably empty the large -wal file, which can reach several hundred MB or GB+ before a checkpoint is done. No amont of pragma settings will override Coredata's apparent reluctance to checkpoint sooner! Then when it does checkpoint (reliably at app start), it fails to clear the -wal file anyway! Consequently, subsequent uses after a checkpoint are all needing force checkpointing again, uncessarily as the main sqlite file now has all the updated data. This will freeze the app for a considerable period (many seconds) and is an unacceptable user experience. Despite many suggestions from Dr. Google I have been unable to overcome CoreData's inability to empty the -wal file, (or to persuade it to checkpoint at smaller file sizes to avoid a freeze). The issue seems to only occur on real devices, whilst on the sim the -wal file is properly emptied by a checkpoint. Any ideas on how to make sure that the -wal file is emptied after a force checkpoint or any pointers as to why this is happening? Thanks
Posted
by DCS17.
Last updated
.
Post marked as solved
2 Replies
1.5k Views
Hi, Novice programmer in SwiftUI and first App published on AppStore. Had a couple of crash reports which I have been able to decipher and sort out. But this one has me stumped! So looking for kindly soul to point me in the right direction. Occurs on iPhone/iPad iOS 14.2 & 14.3. Had a dozen reports over last 6 weeks or so. They are all virtually identical. I have been unable to replicate the crash in simulator or on real devices thru TestFlight. Hours and hours of reading, watching video and learning about analysing crash reports has not helped me. So I post here in desperation! I understand that the exception type is usually unwrapped optionals or force downcast related. But I have scoured my code over and over, and cannot find any "unprotected" unwrapping or force downcasts. So I wonder if there are other possible explanations, and how to go about getting to the bottom of this. Attached is an example crashlog. My App is called SewHelpMe. Crashlog - https://developer.apple.com/forums/content/attachment/65ee872b-a480-4f43-b389-013400e7f6e9 Thanks for any offers of help.
Posted
by DCS17.
Last updated
.