Hello, I'm working on developing an app for a client, whose core functionality includes the ability to share images. One of the specific features required is for users to be able to select a contact within our app and send an image directly to that contact's chat on WhatsApp, without going through the standard iOS Share Sheet. As far as I understand, iOS offers a great integration for sharing content through activity view. However, due to specific project requirements, we are exploring the possibility of sending images directly to a third party app (in this case, WhatsApp) without using activity view, initiating the attempt to share programmatically. Is it technically possible to implement this functionality under current iOS development guidelines? If possible, could you please guide me on which APIs or methods would be suitable to perform this action directly? Are there any special considerations or permissions we should take into account to implement this functionality without violating App Store regulations or third party terms of service such as WhatsApp?

Anyone else getting the below issue when using Shopify's SDK for iOS? Seems odd they just released a new version and it already has an issue embedded in the package.

Hello fellow developers, I've encountered a code signing issue during the archiving process in Xcode and I'm looking for some guidance. Here's the error message I received: codesign command failed (/var/folders/44/968_7v_972vb03blw9l1_sqr0000gn/T/XcodeDistPipeline.~~~k4kX6H/Root/Payload/SweetifyCrm.app/Frameworks/hermes.framework: replacing existing signature /var/folders/44/968_7v_972vb03blw9l1_sqr0000gn/T/XcodeDistPipeline.~~~k4kX6H/Root/Payload/SweetifyCrm.app/Frameworks/hermes.framework: invalid or corrupted code requirement(s) Requirement syntax error(s): line 1:140: unexpected token: SWEETIFY ) Here's what I've tried so far: Cleaned the build folder and rebuilt the archive. Ensured that the correct signing certificate and provisioning profile are in use. Checked .entitlements file for any syntax errors or misplaced tokens. Searched for the token "SWEETIFY" in my project, which is part of the development team name, but didn't find any irregularities. This error seems to be triggered when codesign is executed during the archiving process, specifically with the Hermes framework which is part of my React Native project. I'm using Xcode version 15.0.1, and my project includes Hermes as a JavaScript engine. The issue arises when I try to archive the app for distribution. The word "SWEETIFY" appears to be causing trouble, but it's merely part of the development team's name, (LLC "SWEETIFY"). Has anyone faced a similar issue or could offer some insight into what might be going wrong here? Any help or suggestions would be greatly appreciated! Thank you in advance for your time and help.

Within Xcode when initializing the client via code below, do I insert this code in my app declaration Swift file or can it be just another Swift file included in my app? Thanks! let client = Graph.Client( shopDomain: "your-shop-name.myshopify.com", apiKey: "your-storefront-access-token", locale: Locale(identifier: "en_US") )

We are using AFnetworking in our code base - this framework is build from source code and we not using any binaries provided by AFNetworking team. We have also modify the open source code, so that it is different from the original open source code in a way so that it won't lead to runtime conflicts in case the customers is including similar frameworks in their application. We're using those derivatives of the open source frameworks as a statically linked libraries to our SDK. Now as announce by the AFNetworking Team the SDK is now deprecated -“ As of Jan. 17, 2023, AFNetworking is deprecated and there will be no further releases. This repo will remain online in perpetuity as an archive. There are a couple options for continued AFNetworking use: Copy AFNetworking into your project and compile it directly. This gives you full control over the code. Fork AFNetworking and use the fork in your dependency manager. There will be no official forks but anyone can fork at any time and can even publish those forks under a different name, in accordance with AFNetworking's license. Moving forward, Alamofire is the suggested migration path for networking in modern Swift.  Since major part of our code base extensively use objective C we are reluctant to migrate at the moment. Query for the Apple support team - As AFNetworking announcement clearly states the SDK can still be used and repo will remain available as an archive - If we continue to use forked version of AFNetworking in the way stated above , in our code base will it have any impact on App Submission for the APP store.

I very much love the performance of AppleArchive and how approachable it is, and believe it to be one of the most underrated frameworks in the SDK. In a scenario quite typical, I need to compress files and submit them to a back end, where the server handling the files is not an Apple platform. Obviously, individual files compressed with AA will not be compatible with other systems out of the box, but there are compatible compression algorithms. ZLIB is recommended for cases where cross-platform compatibility is necessary. As I understand it, AA adds additional headers to files in order to support preservation of file attributes, ownership and other data. Following the steps outlined in the docs, I've written code to compress single files. I can easily compress and decompress using AA without issue. To create a proof-of-concept, I've written some code in python using its zlib module. In order to get to the compressed data, it's necessary to handle the AA header fields. The first 64 bytes of a compressed file appear as follows: AA documentation states that ZLIB Level 5 compression is used, and comes in the form of raw DEFLATE data prefixed with two header bytes. In this case, these bytes are 78 5e, which begin at the 28th byte and appear as x^ above. My hope was that seeking to the start of the compressed data, then passing what remains to a decompressor object initialized with the correct WBITS would work. It works fantastically for files 1MB or less in size. Files which are larger only decompress the first megabyte. The decompressor object is reaching EOF, and I've tried various ways of attempting to seek to and concatenate the other blocks, but to no avail. Using the older Compression framework and the method specified here, with the same algorithm, yields different results. I can decompress files of any size using python's zlib module. My assumption is that AppleArchive is doing something differently in order to support its multithreading capabilities, perhaps even with asymmetric encoding where the blocks are not ordered. Is there a solution to this problem? If not, why would one ever use ZLIB versus the much more efficient LZFSE? I could use the older Compression API, but it is significantly slower compressing synchronously, and performance is critical with the application I am adding this feature to.

Problem Description MacBookPro M2, MacOS Sonoma 14.3.1, Xcode 15.3. I'm trying to recompile my project that uses SDL2, from: SDL.org's github using their SDL2-2.30.2.dmg release. "Embed Framework" is required to get around this runtime error: dyld[85171]: Library not loaded: @rpath/SDL2.framework/Versions/A/SDL2 Referenced from: <525E2631-2C23-3E66-96F5-031C734CF0B5> Once the "Embed Framework" step is performed, the Xcode mapping of #include files stored in the loaded framework is undone. Undoing the "Embed Framework" step, puts the name mapping back but the program aborts as before. Either I can compile and obtain a run-time abort or I can not compile and not run the program. I've included a cludge to get around the issue, awaiting your fix (or advice). Replication Details Starting from a “from scratch”, Apple-supplied, “one-liner” (“Hello World”) as follows: Start new project in Xcode, selecting “MacOS”, “Command Line Tool”. Product Name:FrameWorkTest, Team:None, Organization Identifier:frameworktest, Language:C. Create the project in a new folder. with the given (default) settings. hit Apple-R… yay… it compiles and runs! add this line under the #include <stdio.h> #include "SDL2/SDL.h" Now “main.c” source is showing “file not found” against this new #include line. That’s expected. (6) Select FrameWorkTest from Navigator Pane (left hand side) (7) Select “General” tab (middle pane) (8) Finder drag “SDL2.framework” into Xcode’s middle-pane “Frameworks and Libraries” section (check the navigator pane (left pane) and now you have a “Frameworks” group containing “SDL2.framework” After a few seconds the “file not found” indicator in “main.c” vanishes and the program is compilable (Apple+B). The Framework has been integrated (Hooray). After a few seconds the “file not found” returns, though the program is still compilable (this seems to be a real-time parser mismatch with the compiler results, but not the main issue). I found the program is actually runable (Apple+R), probably because “main.c” has not been recompiled. (9) Force a recompile by adding a space to “main.c” (and remove the space) and, once again hit Apple+R. Now compile fails because “SDL2/SDL.h” is not found. (10) Change the #include "SDL2/SDL.h" to #include <SDL2/SDL.h> “file not found” goes away after “Apple+R” forces a recompile. though now the runtime “abort” issue is present. Xcode is seriously confused at this point as putting double-quote version: #include "SDL2/SDL.h" back is fine now (no longer “file not found”) even though the source is back to a failing state. Fine. now to fix the runtime “abort” issue: (11) Select “file view” in the Navigator pane (little folder icon). Select Project name, (topmost “FrameWorkTest” to show settings in middle pane). Select “Build Phases” tab. (12) Drag “SDL2.framework” from the “Frameworks” group in the project Navigator pane (leftmost pane) into “Embed Frameworks” (middle pane) (13) Now Apple+R will not compile (again) with “file not found” and I cannot get the project to compile and run without my “Trick” detailed above. Once the “Trick” is applied and the “file not found” goes away, the embed step (#12) lets the program compile and run - without “abort”. Apple’s prepending of framework name to included files is inconsistent and faulty. The step 12 appears to undo the framework name mapping for #included files found in the framework. This step-by-step repeatable bug crib is not fixed by a “Product->Clean Build Folder…”. Note: If step 12 is applied by doing a Finder drag and not a pane-to-pane drag, a (pointless) second Framework entry is introduced into the project, this confuses things further! CLUDGE WARNING Get around the “file not found” issue (total cludge but awaiting Apple’s real fix) is: Logged in as an admin, in a terminal shell, do this: cd /usr/local/include (if you don’t have this directory; mkdir -p /usr/local/include; cd /usr/local/include) ln -s /Library/Frameworks/SDL2.framework/Headers; mv Headers SDL2 Now in target settings, “Build Settings” tab, find “Header Search Paths” section and add “/usr/local/include” with “recursive” option selected (if it’s not already there). I used a symbolic link (-s) for the trick so that the link is not disrupted when you next upgrade your SDL2.framework. Now, even when you do a Product->Clean Build Folder, the project should build and run without Xcode issues. Additionally, if you’d like to perform “the trick” for SDL2_ttf.framework #include files, do: cd /usr/local/include ln -s /Library/Frameworks/SDL2_ttf.framework/Headers; mv Headers SDL2_ttf in an admin terminal. Aside... Reporting web page renumbers my 1) through 13), though the renumbering does not appear in the preview as it does in the actual post!

Since 2023 Apple have strongly suggested signing XCFrameworks to verify their origins. This has worked perfectly fine for the last year. Seeing that our certificate was about to expire, we revoked it and created a new one which we will use to sign all future releases. However, because that first certificate has been revoked, all previous releases of our XCFramework now have invalid signatures because the certificate they used no longer exists. While an update to the latest XCFramework would solve the issue, that's not always a possibility for people with lower minimum deployment targets that can only run an older version of our XCFramework. In the wwdc video on the topic it states: When the xcframework author's signing certificate expires, Xcode is able to automatically validate that a new certificate for Apple Developer Program identities is from the same developer. Does this mean that if we had not pre-empted the expiry and instead let the certificate expire, we wouldn't have this backwards compatibility issue? The course of action we've had to take is to manually go through all of our releases for the last year and re-sign them with the latest certificate. This doesn't seem like a tenable solution each year. Looking for guidance on how to manage this situation each year.

We are using mach_absolute_time to determine the number of CPU cycles in our app, and from that, we are using it to seed a random number generator. From this random number generator, we are getting a series of random numbers and combining it with other random numbers from another generator not seeded via mach_abolute_time. This combined random number is being sent off device as a unique ID for authentication purposes. I've read through the required reasons for using this API, and I am not sure if it falls under the acceptable use cases. My gut-feeling is that it does not. The following reasons are what Apple lists as acceptable reasons for this API: 35F9.1 Declare this reason to access the system boot time in order to measure the amount of time that has elapsed between events that occurred within the app or to perform calculations to enable timers. Information accessed for this reason, or any derived information, may not be sent off-device. There is an exception for information about the amount of time that has elapsed between events that occurred within the app, which may be sent off-device. 8FFB.1 Declare this reason to access the system boot time to calculate absolute timestamps for events that occurred within your app, such as events related to the UIKit or AVFAudio frameworks. Absolute timestamps for events that occurred within your app may be sent off-device. System boot time accessed for this reason, or any other information derived from system boot time, may not be sent off-device. 3D61.1 Declare this reason to include system boot time information in an optional bug report that the person using the device chooses to submit. The system boot time information must be prominently displayed to the person as part of the report. Information accessed for this reason, or any derived information, may be sent off-device only after the user affirmatively chooses to submit the specific bug report including system boot time information, and only for the purpose of investigating or responding to the bug report. Would anybody be able to confirm that this usage is allowed or if we will need to change it to be in accordance with Apple's new policies regarding the usage of this API? Thanks

We are using AFnetworking in our code base - this framework is build from source code and we not using any binaries provided by AFNetworking team. We have also modify the open source code, so that it is different from the original open source code in a way so that it won't lead to runtime conflicts in case the customers is including similar frameworks in their application. We're using those derivatives of the open source frameworks as a statically linked libraries to our SDK. Now as announce by the AFNetworking Team the SDK is now deprecated - " As of Jan. 17, 2023, AFNetworking is deprecated and there will be no further releases. This repo will remain online in perpetuity as an archive. There are a couple options for continued AFNetworking use: Copy AFNetworking into your project and compile it directly. This gives you full control over the code. Fork AFNetworking and use the fork in your dependency manager. There will be no official forks but anyone can fork at any time and can even publish those forks under a different name, in accordance with AFNetworking's license. Moving forward, Alamofire is the suggested migration path for networking in modern Swift. " Since major part of our code base extensively use objective C we are reluctant to migrate at the moment. Query: - As AFNetworking announcement clearly states the SDK can still be used and repo will remain available as an archive - If we continue to use forked version of AFNetworking in the way stated above in our code base - will it have any impact on App Submission for the APP store ?

For our application, we are aiming to have full control over setting and locking the camera exposure settings when taking a video. We’re working with Apple’s AVFoundation framework for a range of devices, but most of the development is focused on the iPad 8 front camera. The manual settings are specific to our use, so we aim to use the custom exposure mode with e.g ISO = 100, exposureDuration = 1/60, and a fixed white balance. The duration, ISO, and white balance are all set in advance of recording, but when we begin we can see that something is still adjusting and compensating for lighting changes. We then also tried locking the exposure mode after setting the custom values, but there appears to be a delay in this lock taking effect. While tracking the ISO during a recording, we see that the ISO values change in the first second of the recording, leading to oversaturated images, despite our efforts to keep it locked. This is our attempt to lock the settings using custom mode, which we don’t adjust ourselves during the recording, but it does not work as expected: func setCameraSettings(newValueISO: Float, newValueDuration: CMTime){ do { try cameraDevice?.lockForConfiguration() cameraDevice?.automaticallyAdjustsVideoHDREnabled = false cameraDevice?.setExposureModeCustom(duration: newValueDuration, iso: newValueISO, completionHandler: { [self] _ in cameraDevice?.setWhiteBalanceModeLocked(with: cameraDevice!.deviceWhiteBalanceGains) if ((cameraDevice!.isFocusModeSupported(.locked))) { do { cameraDevice!.focusMode = .locked debugPrint("Focus mode set to locked.") } } cameraDevice?.unlockForConfiguration() }) } catch { debugPrint("Error adjusting the exposure") cameraDevice?.unlockForConfiguration() } } We then tried to lock the exposure mode after setting the custom values, but it then changes during the first second of the recording. We also explicitly tried setting exposureTargetBias to 0, but this made no difference. func setCameraSettings(newValueISO: Float, newValueDuration: CMTime){ guard let camera = cameraDevice else { return } do { if camera.isExposureModeSupported(.custom) { do { try camera.lockForConfiguration() let customExposureBias: Float = 0 //camera.setExposureTargetBias(customExposureBias, completionHandler: nil) if camera.isExposureModeSupported(.custom) { camera.setExposureModeCustom(duration: newValueDuration, iso: newValueISO) { [weak camera ] _ in guard let camera = camera else { return } if camera.isExposureModeSupported(.locked) { camera.exposureMode = .locked } } } camera.unlockForConfiguration() print("Exposure settings locked with custom values.") } catch { print("Failed to lock configuration for capture device: \(error.localizedDescription)") camera.unlockForConfiguration() } } else { print("Custom exposure mode is not supported.") } } } We would very much appreciate input on how to keep the manually selected camera settings fixed throughout the video recording.

Hi, I am splitting my iOS app into smaller components, the natural way of doing this is to create static libraries that I can link with the main binary. I did succeed at making small static libraries (.a) and link them, but I was struggling with static framework where I have color assets. Finally I was able to make it work by going to the app target > Build Phases > Copy Bundle Resources and add there the .xcassets from the static framework I created. The confusion on my side is that the assets are accessed from the Framework code not from the app target code, and the guidance I am asking for is: How to create and link a static framework on iOS so that the framework can load and use it's own defined assets without having to do the Copy Bundle Resources step. Best Regards, Ion

I have a React-Native App that I am trying to build to iOS using Xcode. When I build to my iPhone 12 Mini (iOS 17.4.1), the app works perfectly. When I build to my iPhone 7 Plus (iOS 15.8.2), the app pauses running immediately, and Xcode displays the following in the log: dyld[935]: Symbol not found: (_JSGlobalContextSetInspectable) Referenced from: '/private/var/containers/Bundle/Application/2579192B-74C5-4B54-AA59-948C49A4A7CA/MANHUNT2.app/MANHUNT2' Expected in: '/System/Library/Frameworks/JavaScriptCore.framework/JavaScriptCore' The app used to work perfectly on both phones, but this error has been happening recently, and I am unsure of the cause. Cleaning build folder and deleting derived data has not fixed the issue. Xcode: Version 15.3 React-Native: 0.73.6 Working Phone: iOS 17.4.1 Non-Working Phone: iOS 15.8.2

I have been working with a framework to add multiplayer support to my app. The app runs on test devices, simulators, and archives perfectly fine and the app is fine without the framework. But when I go to distribute the app, I see get this error related to the multiplayer framework I have added. I have tried updating the minimumOSVersion to 9.0, 10.0, 12.0, and 13.0 everywhere (info.plist, deployment info, build settings, etc) and they all match with each build/archive but no matter what I can't get fix this error. This error only shows up when I go to distribute the app to the store. Any ideas on what to try or how to fix this issue? I've attached a screenshot of the issue below.

We are using AFnetworking in our code base - this framework is build from source code and we not using any binaries provided by AFNetworking team. We have also modify the open source code, so that it is different from the original open source code in a way so that it won't lead to runtime conflicts in case the customers is including similar frameworks in their application. We're using those derivatives of the open source frameworks as a statically linked libraries to our SDK. Now as announce by the AFNetworking Team the SDK is now deprecated -“ As of Jan. 17, 2023, AFNetworking is deprecated and there will be no further releases. This repo will remain online in perpetuity as an archive. There are a couple options for continued AFNetworking use: Copy AFNetworking into your project and compile it directly. This gives you full control over the code. Fork AFNetworking and use the fork in your dependency manager. There will be no official forks but anyone can fork at any time and can even publish those forks under a different name, in accordance with AFNetworking's license. Moving forward, Alamofire is the suggested migration path for networking in modern Swift.  Since major part of our code base extensively use objective C we are reluctant to migrate at the moment. Query for the Apple support team - As AFNetworking announcement clearly states the SDK can still be used and repo will remain available as an archive - If we continue to use forked version of AFNetworking in the way stated above , in our code base will it have any impact on App Submission for the APP store.

Hello, When you integrate framework linked statically, the usage is that those framework provide a bundle in which they put their PrivacyInfo.xcprivacy file. If you decompress an .ipa file you submit to Apple, you can see this bundle at the root. The problem is that the PrivacyInfo.xcprivacy files inside bundles seem not to be scan by Apple in the privacy process. Thus Apple send us issues about missing privacy. Have you already heard about this problem ? Probably link to what i am saying : Firebase issue #12557 Thank you very much for your feedback !

Hello, What are the guidelines for mergeable libraires regarding privacy data ? In particular where do we put the PrivacyInfo.xcprivacy file in this situation, so as Apple process can scan it when we upload the package of the app. Thank you.

We're distributing an XCFramework to a customer to create their own apps. With the new XCFramework signing requirements, we have a question with regards the way how to implement it. We're using a few of the frameworks on the list https://developer.apple.com/support/third-party-SDK-requirements/ including [AFNetworking], as a dependencies for our framework. We are building those frameworks from source code and not using any binaries provided by any third-party. We also modify the open source code, so that it is different from the original open source code in a way so that it won't lead to runtime conflicts in case the customers is including similar frameworks in their application. We're using those derivatives of the open source frameworks as a statically linked libraries to our SDK. Questions: Do we need to sign the third party frameworks of which we have cloned source code and using it within our SDK Framework? Is it required that the XCFramework built this way is signed when it is delivered to a third party and they use it in their app?

Since yesterday (03/22/24) we are unable to upload new or existing builds to AppStoreConnect. We get the following error - “Error ITMS-90432 Unexpected file found in Frameworks. MyApp.app/Frameworks/Configurations” file is in the Frameworks directory, but the Swift runtime libraries are the only files permitted in that directory. Please remove this file and upload a new build. (ID: 57e219ea-d27e-465d-9e9b-ec41d3a0b1f7). We have tried rebuilding targerts with no changes for Builds that use to upload ok and they now get the same error too. Is this an appstoreconnect bug? If not where is the Frameworks directory and how do we remove the file?