I have an Xcode project based on the multiplatform template. The SwiftUI-based app has a macOS target and an iOS target. I want to release the macOS app as a free download, but charge for the iOS app.
In App Store Connect, I don't see a way to set a price for the iOS app only. Can this be done, or do I need two projects with different bundle IDs?
Post
Replies
Boosts
Views
Activity
I have a TestFlight build of my Mac app installed on Ventura (13.2.1).
If I open the app, then restart macOS with "Reopen windows when logging back in" checked, it opens again as expected on login.
If I enable "Open at Login" from the app's dock item but don't open the app, then restart macOS, it bounces in the dock for 90 seconds or so but never opens. If I click the item in the dock afterwards, it opens immediately.
Any ideas on what could cause this behavior? I see nothing in the system log, crash reports, etc.
The current App Store requirements for iPad screenshots are:
12.9-inch (iPad Pro (6th generation, 5th generation, 4th generation, 3rd generation))
2048 x 2732
12.9-inch (iPad Pro (2nd generation))
2048 x 2732
Since the images sizes are the same, can I upload the same set of images for both? Or does one set have to show the newer iPad without a Home button, and the the other set the older iPad with a Home button?
My understanding is that iOS app group names must begin with "group.", but macOS group names must begin with the team identifier.
If I check a "group." name in the iOS section, it's also added to the macOS section, despite being invalid.
If I add a "team-id:" name in the macOS section, it's also added to the iOS section, and marked in red as invalid. If I uncheck it from the iOS section, it also gets removed from the macOS section.
Is there a way to define the equivalent group names in the two sections?
Xcode 14.1b3 screenshot:
I'm building a macOS + iOS SwiftUI app using Xcode 14.1b3 on a Mac running macOS 13.b11. The app uses Core Data + CloudKit.
With development builds, CloudKit integration works on the Mac app and the iOS app. Existing records are fetched from iCloud, and new records are uploaded to iCloud. Everybody's happy.
With TestFlight builds, the iOS app has no problems. But CloudKit integration isn't working in the Mac app at all. No existing records are fetched, no new records are uploaded.
In the Console, I see this message:
error: CoreData+CloudKit: Failed to set up CloudKit integration for store: <NSSQLCore: 0x1324079e0> (URL: <local file url>)
Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.apple.cloudd was invalidated: failed at lookup with error 159 - Sandbox restriction." UserInfo={NSDebugDescription=The connection to service named com.apple.cloudd was invalidated: failed at lookup with error 159 - Sandbox restriction.}
I thought it might be that I was missing the com.apple.security.network.client entitlement, but adding that didn't help.
Any suggestions what I might be missing? (It's my first sandboxed Mac app, so it might be really obvious to anyone but me.)
It's really convenient to use the Mac keyboard in the simulator, but it hides potential problems with how the software keyboard is managed in the app. Is there a secret setting to enable both at the same time?
When I use "Build With Timing Summary" in Xcode I can see elapsed times in the build log. When I export the log (or copy/paste a section), the times aren't included. Is there a way to include them so I can analyze the results?
My app uses UIActivityViewController to let the user share a URL. This works normally on iOS 13.
On iOS 14, if the user selects Messages from the share sheet, the URL in Messages has been changed so that the domain is 127.0.0.1.
This doesn't happen if they choose Copy to send it to the clipboard. In that case, the URL is exactly as expected.
Is this a bug? Did I miss some new security setting?
I have an app that launches fine on device and the simulator from Xcode 11.2 on macOS 10.15.1.I just upgraded to Xcode 11.3 and macOS 10.15.2. The app still launches fine from Xcode to a device. When launching on the simulator, it immediately crashes with "Message from debugger: Terminated due to signal 6". This happens with 13.3 and 11.4 simulated devices. Stack trace below. It doesn't look to me like it's even getting into the app code. Anyone else seeing this?#00x00007fff523d5bea in __abort_with_payload ()#10x00007fff523d74f3 in abort_with_payload_wrapper_internal ()#20x00007fff523d74a3 in abort_with_reason ()#30x00007fff52469974 in pthread_self.cold.1 ()#40x00007fff52462fe3 in pthread_self ()#50x0000000106eff16b in __tsan::cur_thread() ()#60x0000000106ed4985 in wrap_sysctlbyname ()#70x00007fff52470331 in assert_simulator_supported_host ()#80x00007fff4ff167c1 in libSystem_initializer ()#90x0000000106e063a7 in ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) ()#100x0000000106e067b8 in ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) ()#110x0000000106e019a2 in ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) ()#120x0000000106e0190f in ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) ()#130x0000000106e0190f in ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) ()#140x0000000106e0190f in ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) ()#150x0000000106e007a6 in ImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) ()#160x0000000106e00846 in ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) ()#170x0000000106df5046 in dyld::initializeMainExecutable() ()#180x0000000106df90fc in dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) ()#190x0000000106df41cd in start_sim ()#200x0000000111dfa8cc in dyld::useSimulatorDyld(int, macho_header const*, char const*, int, char const**, char const**, char const**, unsigned long*, unsigned long*) ()#210x0000000111df8575 in dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) ()#220x0000000111df3227 in dyldbootstrap::start(dyld3::MachOLoaded const*, int, char const**, dyld3::MachOLoaded const*, unsigned long*) ()#230x0000000111df3025 in _dyld_start ()