Search Results

The fact that this bug that's related to the core features of the SPM still exists after several versions of the IDE is mindblowing. Whenever I change branches, it starts to update dependencies altough all branches have the same .resolved file in them and failing to do so randomly is extremely frustrating. Closing Xcode before switching branches doesn't always work either. I have to randomly try resetting package caches multiple times and restarting the IDE several times to make it work again. A collosal waste of time.

Sometimes upload fails. You have to reload again the specific image. yYou do not show the screenshots section, that would be useful.

Hello, If you want to get approval from the Apple Store, you need to ensure that your dating app is unique and also provides a valuable environment for users. One of the reasons the app is rejected is because it failed to have a unique value proposition. You should ensure your app offers a distinct set of features or functionalities to stand out from the crowd. Other than that, here are some factors you shouldn’t overlook if you want to pass guideline 4.3: Ensure that your app actually addresses the needs of a particular/target group. Features are up to the market standards. Prioritize high-quality and visually appealing Design. Make sure to have transparency. To learn more in detail about how to submit your app to the App Store, check out this link: https://www.nimbleappgenie.com/blogs/submit-app-to-app-store/

Hello Quinn, Your question: What are the array elements? My app comprises about 500 methods, many of them contain pairs of deprecated… -> Elements are NSStrings, NSArrays, NSMutableArrays, NSNumbers, NSSets, NSMutableSets I don't understand what you mean by I think you should take this opportunity to factor out the common code so that you only have one copy of your archiving code. What do you mean by common code? Do you mean deprecated code? … only have one copy of your archiving code? As already said in my previous reply: Your proposal works. I need to do a big job to change them all bit by bit. What is irritating is this Console feedback: *** -[NSKeyedUnarchiver validateAllowedClass:forKey:] allowed unarchiving safe plist type ''NSString' (0x1f30548c8) [/System/Library/Frameworks/Foundation.framework]' for key 'NS.objects', even though it was not explicitly included in the client allowed classes set: '{( 'NSMutableArray' (0x1f304d690) [/System/Library/Frameworks/CoreFoundation.framework] )}'. This will b

Hello, I have encountered the same issue and I have found this work around: Within your workflow add the Notarize - macOS step Add this in your ci_post_xcodebuild.sh script: #!/bin/bash -x # Set the directory paths and versions APP_PATH=${CI_DEVELOPER_ID_SIGNED_APP_PATH}/ INFO_PLIST_PATH=${APP_PATH}/Contents/Info.plist APP_VERSION=$(/usr/libexec/PlistBuddy -c Print CFBundleShortVersionString $INFO_PLIST_PATH) ZIP_PATH=/Volumes/workspace/YOUR-APP-$APP_VERSION-$CI_BUILD_NUMBER.zip echo Post-build script started. # Compress the application for notarization ditto -c -k --keepParent $APP_PATH $ZIP_PATH notary_output=$(xcrun notarytool submit $ZIP_PATH --apple-id $XCODE_CLOUD_ID --password $APP_SPECIFIC_PASSWORD --team-id $TEAM_ID --wait 2>&1) # Staple notarization echo Notarization succeeded xcrun stapler staple $APP_PATH exit_status=$? # Check if the command failed if [ $exit_status -ne 0 ]; then echo Notary tool submission failed with exit status $exit_status echo Output: $notary_output

I am encountering a similar problem as you, this time on MacOS Sonoma 14.5. Our team's code for integrating SwiftData and CloudKit is similar to yours and closely follows the official documentation from Apple regarding SwiftData and CloudKit: https://developer.apple.com/documentation/swiftdata/syncing-model-data-across-a-persons-devices Our code worked on previous versions of Sonoma, but since updating to 14.5, we have consistently encountered the issue you are having, and it is infuriating. I am currently investigating why ours is failing, but it is frustrating to follow the documentation and still see our app crash.

Hello Quinn, I tried to implement your proposal. Need I to implement secure coding support as in the example? According to the example implementing 'secure coding support' requires about a dozen lines of code. What I have done: Deprecated code tmp = [NSKeyedArchiver archivedDataWithRootObject:savedSettingsArray]; settingsArray = [NSKeyedUnarchiver unarchiveObjectWithData:tmp]; (tmp is NSData, savedSettingsArray + settingsArray are NSMutableArray) I tried this: tmp = [NSKeyedArchiver archivedDataWithRootObject:savedSettingsArray requiringSecureCoding:true error: nil]; settingsArray = [NSKeyedUnarchiver unarchivedObjectOfClass: [NSMutableArray class] fromData:tmp error:nil]; Result: it works. Question: My app comprises about 500 methods, many of them contain pairs of deprecated NSKeyedArchiver+NSKeyedUnarchiver. I can't change these all at once. The chance of coding errors is great. So, I try to make changes bit by bit. How long does the deprecated code works? Although the corrected lines of code work the Conso

I'm seeing similar problems. I think UI testing in Xcode cloud cannot be used (yet...). I have simple test code like this: XCTAssert(buttonBack.waitForExistence(timeout: 1.0)) ... so it's supposed to wait for existence of that button for 1 second, and then fail the test if it cannot find the button, right? It works fine locally (of course), but it also works fine in Bitrise. But when running in Xcode Cloud, it fails there and I have this log: Just look at the timestamps to the right, it's looking for that button way longer than the specified time. and it even retries a few times before failing the test there.

In the latest iOS build, Safari Mobile Extensions behave differently, with more aggressive freezing of background processes. Previously, these processes would suspend after 30 seconds of browser or user inactivity, but now they suspend even more quickly and sometimes fail to wake up when expected. Events that should trigger a wake-up, like webNavigation.onCommitted or tabs.onUpdated, often fail to do so, although clicking an extension button to open a Popup window does wake up the process. However, external events like messages from content scripts can still wake up the background process. Overall, it seems that the background process is unexpectedly suspended and fails to wake up as expected in many cases.

I'm having the same issue on Xcode 15.4, and not on 15.3. I can reproduce this issue with these steps: Create a new iOS app. Remove Mac for iPad, add MacCatalyst target. Add Sentry SDK package from https://github.com/getsentry/sentry-cocoa.git, adding Sentry and SentrySwiftUI to target. Clean build folder, build and run to Mac. Result: -> Xcode 15.3, works. -> Xcode 15.4, initially fails. Build and run again immediately after, works. On Xcode 15.4, any time that I clean and then build, it first fails and then will succeed. After this the build will always succeed, unless cleaned in between. This has caused our Xcode Cloud builds that recently updated to using Xcode 15.4 to fail, as they just fail and don't try to build again.