I am working on a white label product and have around 400+ white label customers with minor changes in color, assets, and strings. I am considering creating a workspace and adding all customer projects to the workspace. However, I am unsure about the limitations of Xcode workspace. How many projects can be added to an Xcode workspace?

SecItemCopyMatching crash occurs while iOS creating RSA. Test device is iPhone6s plus. How can I solve this? The crash log is as follows: 0 libobjc.A.dylib 0x0000000198964cf4 objc_msgSend + 20 (:-1) 1 Security 0x0000000189989968 SecTokenItemCreateFromAttributes + 80 (SecItem.m:996) 2 Security 0x00000001898f6db0 SecItemResultCopyPrepared + 2876 (SecItem.m:1195) 3 Security 0x00000001898ea5fc SecItemResultProcess + 376 (SecItem.m:1252) 4 Security 0x00000001898e0168 __SecItemCopyMatching_block_invoke_2 + 324 (SecItem.m:1893) 5 Security 0x00000001898e0a70 __SecItemAuthDoQuery_block_invoke + 524 (SecItem.m:1591) 6 Security 0x00000001898df2c0 SecItemAuthDoQuery + 1204 (SecItem.m:1557) 7 Security 0x00000001898e0614 __SecItemCopyMatching_block_invoke + 104 (SecItem.m:1883) 8 Security 0x00000001898e665c SecOSStatusWith + 48 (SecItem.m:331) 9 Security 0x00000001898e0374 SecItemCopyMatching + 364 (SecItem.m:1882)

In Xcode Version 15.3 (15E204a) I am getting this warning: Class AKAlertImageURLProvider is implemented in both /Library/Developer/CoreSimulator/Volumes/iOS_21E213/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS17.4.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/AuthKit.framework/AuthKit (0x123719508) /Library/Developer/CoreSimulator/Volumes/iOS_21E213/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS17.4.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/AuthKitUI.framework/AuthKitUI One of the two will be used. Which one is undefined. and also objc[2875]: Class AKBiometricRatchetUtility is implemented in both /Library/Developer/CoreSimulator/Volumes/iOS_21E213/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 17.4.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/AuthKit.framework/AuthKit (0x12371ab10) and /Library/Developer/CoreSimulator/Volumes/iOS_21E213/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 17.4.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/AuthKitUI.framework/AuthKitUI (0x152a1d810). One of the two will be used. Which one is undefined.

Hi all, I'm attempting to generate an XCFramework that must maintain ABI stability. The framework is created from an SPM using the attached script generate-FK.sh. I does not work. Removing the flag BUILD_LIBRARY_FOR_DISTRIBUTION=YES and adding the flag -allow-internal-distribution to xcodebuild -create-xcframework everything is fine. Despite this resolves the problem, it results in the generated module not being ABI stable. However, when attempting the script approach, it generates the XCFramework but when used it raises an error in arm64-apple-ios-private.swiftinterface with no such file or module as soon as it encounters an import statement for ModuleX reading it. The package structure is attached as Package.swift and te obtained result XCFramework structure is as follows: MyLibrary.xcframework ├── Info.plist ├── ios-arm64 │ └── MyLibrary.framework │ ├── Headers │ │ ├── ModuleH-Swift.h │ │ ├── ModuleH.modulemap │ │ ├── ModuleC-Swift.h │ │ ├── ModuleC.modulemap │ │ ├── ModuleA-Swift.h │ │ ├── ModuleA.modulemap │ │ ├── MyLibrary-Swift.h │ │ └── MyLibrary.modulemap │ ├── Info.plist │ ├── Modules │ │ └── MyLibrary.swiftmodule │ │ ├── arm64-apple-ios.abi.json │ │ ├── arm64-apple-ios.swiftdoc │ │ └── arm64-apple-ios.swiftmodule │ └── MyLibrary └── ios-arm64_x86_64-simulator └── MyLibrary.framework ├── Headers │ ├── ModuleH-Swift.h │ ├── ModuleH.modulemap │ ├── ModuleC-Swift.h │ ├── ModuleC.modulemap │ ├── ModuleA-Swift.h │ ├── ModuleA.modulemap │ ├── MyLibrary-Swift.h │ └── MyLibrary.modulemap ├── Info.plist ├── Modules │ └── MyLibrary.swiftmodule │ ├── arm64-apple-ios-simulator.abi.json │ ├── arm64-apple-ios-simulator.swiftdoc │ ├── arm64-apple-ios-simulator.swiftmodule │ ├── x86_64-apple-ios-simulator.abi.json │ ├── x86_64-apple-ios-simulator.swiftdoc │ └── x86_64-apple-ios-simulator.swiftmodule ├── MyLibrary └── _CodeSignature └── CodeResources It's worth mentioning that the library must be compatible with both Objective-C and Swift, and Modules A, C, and H are imported into the MyLibrary module as @_exported modules, that is why I've included the headers and module maps. What is wrong? Thank you in advance for your assistance. Files: generate-FK.sh Package.swift

I have my own framework, Which is working fine since long time and also compiling in xcode 15.2. As soon as i updated xcode to xcode 15.3, My code is not compiling. I am getting below error. module '' does not use additional module map '.framework/Modules/module.modulemap' not used when the module was built I have both objective c and swift files in my framework.

I am starting a new Xcode Project for macOS app. During the initial development I found that some part of the app should be shared between different targets like macOS App, Quick Look etc. The goal was to user Framework. By selecting Project in Project navigator and using the plus icon, I have created a new Framework target and called it Shared. Next, in my App Project I have added it into the project and checked if it is correctly linked. The framework was Embedded and Signed. Both targets have the same Signing & Capabilities settings. After I move a code into Shared framework it was time for first run. Unfortunately, the app is crashing instantly, and I am getting the error: dyld[65044]: Library not loaded: @rpath/Shared.framework/Versions/A/Shared Referenced from: <2B03FB61-86B3-31E5-A2A4-F18F43AEC875> /Users/{User}/Library/Developer/Xcode/DerivedData/AppName-fjfbylcqrxaiobgohprplbaohgbw/Build/Products/Debug/AppName e.app/Contents/MacOS/AppName Reason: tried: '/Users/{User}/Library/Developer/Xcode/DerivedData/AppName-fjfbylcqrxaiobgohprplbaohgbw/Build/Products/Debug/Shared.framework/Versions/A/Shared' (code signature in <DD201FE7-57E2-33B1-AD7C-E61BA1345673> '/Users/{User}/Library/Developer/Xcode/DerivedData/AppName-fjfbylcqrxaiobgohprplbaohgbw/Build/Products/Debug/Shared.framework/Versions/A/Shared' not valid for use in process: mapping process and mapped file (non-platform) have different Team IDs), '/Users/{User}/Library/Developer/Xcode/DerivedData/AppName-fjfbylcqrxaiobgohprplbaohgbw/Build/Products/Debug/AppName.app/Contents/Frameworks/Shared.framework/Versions/A/Shared' (code signature in <DD201FE7-57E2-33B1-AD7C-E61BA1345673> '/Users/{User}/Library/Developer/Xcode/DerivedData/AppName-fjfbylcqrxaiobgohprplbaohgbw/Build/Products/Debug/AppName.app/Contents/Frameworks/Shared.framework/Versions/A/Shared' not valid for use in process: mapping process and mapped file (non-platform) have different Team IDs), '/Users/{User}/Library/Developer/Xcode/DerivedData/AppName-fjfbylcqrxaiobgohprplbaohgbw/Build/Products/Debug/AppName.app/Contents/Frameworks/Shared.framework/Versions/A/Shared' (code signature in <DD201FE7-57E2-33B1-AD7C-E61BA1345673> '/Users/{User}/Library/Developer/Xcode/DerivedData/AppName-fjfbylcqrxaiobgohprplbaohgbw/Build/Products/Debug/AppName.app/Contents/Frameworks/Shared.framework/Versions/A/Shared' not valid for use in process: mapping process and mapped file (non-platform) have different Team IDs) The Team ID is set properly in Build Settings for both targets. The Bundle Identifier is different and the rest of the settings seems to be correct. I tried changing and juggling the settings related to signing the framework, but it didn't help. I am totally lost without any other idea to fix it... I will be glad for some help.

IN endpoint security events related to user login/logout activity (as well in lock/unlock and remote session attach/detach) there is a graphical session identifier which is a 32 bit integer typedef struct { es_string_token_t username; ** es_graphical_session_id_t graphical_session_id;** } es_event_lw_session_login_t; Documentation describes it as an opague number @brief es_graphical_session_id_t is a session identifier identifying a on-console or off-console graphical session. A graphical session exists and can potentially be attached to via Screen Sharing before a user is logged in. EndpointSecurity clients should treat the graphical_session_id as an opaque identifier and not assign special meaning to it beyond correlating events pertaining to the same graphical session. Not to be confused with the audit session ID. */ typedef uint32_t es_graphical_session_id_t; Question: is there a way to get this graphical session identifier outside of endpoint security framework, for ex. from process id or audit token? Is there an API for that?

Hi all, I'm attempting to generate an XCFramework that must maintain ABI stability. The framework is created from an SPM using the attached script generate-FK.sh. I does not work. Removing the flag BUILD_LIBRARY_FOR_DISTRIBUTION=YES and adding the flag -allow-internal-distribution to xcodebuild -create-xcframework everything is fine. Despite this resolves the problem, it results in the generated module not being ABI stable. However, when attempting the script approach, it generates the XCFramework but when used it raises an error in arm64-apple-ios-private.swiftinterface with no such file or module as soon as it encounters an import statement for ModuleX reading it. The package structure is attached as Package.swift and te obtained result XCFramework structure is as follows: MyLibrary.xcframework ├── Info.plist ├── ios-arm64 │ └── MyLibrary.framework │ ├── Headers │ │ ├── ModuleH-Swift.h │ │ ├── ModuleH.modulemap │ │ ├── ModuleC-Swift.h │ │ ├── ModuleC.modulemap │ │ ├── ModuleA-Swift.h │ │ ├── ModuleA.modulemap │ │ ├── MyLibrary-Swift.h │ │ └── MyLibrary.modulemap │ ├── Info.plist │ ├── Modules │ │ └── MyLibrary.swiftmodule │ │ ├── arm64-apple-ios.abi.json │ │ ├── arm64-apple-ios.swiftdoc │ │ └── arm64-apple-ios.swiftmodule │ └── MyLibrary └── ios-arm64_x86_64-simulator └── MyLibrary.framework ├── Headers │ ├── ModuleH-Swift.h │ ├── ModuleH.modulemap │ ├── ModuleC-Swift.h │ ├── ModuleC.modulemap │ ├── ModuleA-Swift.h │ ├── ModuleA.modulemap │ ├── MyLibrary-Swift.h │ └── MyLibrary.modulemap ├── Info.plist ├── Modules │ └── MyLibrary.swiftmodule │ ├── arm64-apple-ios-simulator.abi.json │ ├── arm64-apple-ios-simulator.swiftdoc │ ├── arm64-apple-ios-simulator.swiftmodule │ ├── x86_64-apple-ios-simulator.abi.json │ ├── x86_64-apple-ios-simulator.swiftdoc │ └── x86_64-apple-ios-simulator.swiftmodule ├── MyLibrary └── _CodeSignature └── CodeResources It's worth mentioning that the library must be compatible with both Objective-C and Swift, and Modules A, C, and H are imported into the MyLibrary module as @_exported modules, that is why I've included the headers and module maps. What is wrong? Thank you in advance for your assistance.

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.

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!

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.

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

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 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 ?