i'm using dlopen() to load dynamic framework from documents directory, it's working good below iOS10, but in iOS10 it does not work anymore，and console's log is:
file system sandbox blocked mmap() of '/var/mobile/Containers/Data/Application/71EB4588-A83F-4AF0-9409-DD09AFB2CA77/Documents/MyDylib.framework/MyDylib'
how can i solve this problem?
in iOS10 the framework cannot save to the Documents dir or subdir. you must put the framework under to the YouAppName.app/
Related
This is the full error-message:
Cannot show Automatic Strong Passwords for app bundleID: com.ckbusiness.Wishlists due to error: Cannot identify the calling
app's process. Check teamID and bundleID in your app's
application-identifier entitlement
What am I missing here??
We have the same issue with Xcode 12.2 and iOS 14.2 and applied more details on the Apple Developer forum.
Can this be related? The documentation of the Associated Domain File shows a new section at the bottom about macOS 11 and iOS 14:
Starting with macOS 11 and iOS 14, apps no longer send requests for apple-app-site-association files directly to your web server. Instead, they send these requests to an Apple-managed content delivery network (CDN) dedicated to associated domains.
Update - December 3:
We checked many things:
Code signing
Our target is set to "Automatically managing signing".
In App Store connect we looked up the the entitlement:
Select app
Select "Activity"
Select a Build
Scroll down to "Store Information", the right column shows the Entitlements.
The com.apple.developer.team-identifier matches the prefix in the application-identifier. The latter matches exactly with the value in the apps array in the apple-app-site-association file on our website.
However, when performing Build & Run with Xcode on device, the debug app is signed with a different Signing Identity:
Apple Development: (other ID than com.apple.developer.team-identifier)
An estimated guess is that this would create a mismatch with the apple-app-site-association file. Hence we added this new id to the existing apple-app-site-association file and uploaded on our server:
{
"webcredentials": {
"apps": ["ABCDEF1234.com.domain.appName", // Release ID from App Store
"1234ABCDEF.com.domain.appName"] // Debug ID from Xcode
}
}
Tried again, still the same error.
Also performed the usual stuff like:
Uninstall app from iPhone and reboot iPhone
Clean Build Folder in Xcode
Delete Xcode folder DerivedData from /Users/xxx/Library/Developer/Xcode and rebooted MacBook
Availability of apple-app-site-association file
While updating this file on our server, we found a docu update. In June 2019 (when we launched this particular app) it mentions to place the file in 2 folders:
https://<fully qualified domain>/apple-app-site-association
https://<fully qualified domain>/.well-known/apple-app-site-association
Note: Currently only the later .well-known directory is mentioned.
It appeared that our file was only in the first folder. So we duplicated it and checked again, but still the error is shown.
To rule out that it takes time for iOS 14 to update changes of the apple-app-site-association file based on the new Apple-managed content delivery network (CDN), we even used the mode option in the entitlements file:
While you’re developing your app, if your web server is unreachable from the public internet, you can use the alternate mode feature to bypass the CDN and connect directly to your private domain.
You enable an alternate mode by adding a query string to your associated domain’s entitlement as follows:
webcredentials:doamin.com?mode=developer
Again, no luck.
TestFlight version
To avoid using Xcode debugger and it's debug signing, archived the Xcode 12.2 build and submitted it to App Store. Verified the entitlements from the build in App Store Connect as described above. They match the apple-app-site-association file.
Released for internal TestFlight testing and tested on device. Tapping the first password text field does not show the password suggestion.
Conclusion
Although we seem out of options, hopefully any of these exercises can inspire others to identify a solution. Or it's just a massive Apple bug and we need to wait for a fix from them.
Work again in Version 13.0 beta (13A5155e) !
I have updated a currently submitted Titanium app and added a watch extension using swift.
Everything works fine if I build and test on sim and build directly to device. I only get an issue when I submit the app to the Apple app store (via XCode Organizer).
The binary submits, passing validation but I get am email from iTunes Connect as follows:
Dear developer,
We have discovered one or more issues with your recent delivery for "xxxxxxxxxxx". To process your delivery, the following issues must be corrected:
Invalid Swift Support - The SwiftSupport folder is missing. Rebuild your app using the current public (GM) version of Xcode and resubmit it.
Once these issues have been corrected, you can then redeliver the corrected binary.
It seems as though it may be related to a build setting: Embedded Content Contains Swift Code.
It looks like this needs to be set to Yes if the Titanium project contains embedded Swift.
As of now I am stuck as I cannot submit the app. Is this a Ti problem or is there another step I should follow?
XCode: 7.3, SDK: 5.2.2.GA - Project created and built using only the Ti CLI.
First you should check your .ipa file by
unzip yourapp.ipa
If the only Payload exists, the Apple reject your app.
You should create SwiftSupport/iphoneos directory and put the appropriate
swift library files.
You can know which libraries are necessary by checking Payload/yourapp.app/Framesworks. But this library files can not be used as SwiftSupport/iphoneos.
You must copy the appropriate libraries from your mac's /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphoneos directory. The file names are same as the above Payload/yourapp.app/Frameworks but the contents are different.
After you get the Payload and SwiftSupport directory, do package these directories by
$ zip -r yournewapp.ipa Payload SwiftSupport
(Remark: remove all .DS_Store files if exist)
Then Apple accespt yournewapp.ipa.
For future reference: I had to Archive the Titanium project through Xcode because one of my third-party libraries requested to execute a script in the Build phases.
Received the same message from Apple and fortunately fixed it just changing the Embedded Content Contains Swift Code to No.
You should choose "Save for iOS App Store Deployment" option at the time of exporting ipa file.
This issue has now be resolved, there is a new version of the Titanium SDK, 6.0.1.GA that specifically has a fix in for this issue. I have now created, submitted and have a Titanium app with associated watch app now published in the app store.
After updating my XCode to version 4.4 it seems to be impossible to retrieve Application Data from my devices.
In Xcode 4.3 (and all previuos version) I downloaded my Application Data (like SQLite databases and files I created) through the organizer (Organizer -> Devices -> "Device" -> Applications -> "Application" -> Download).
With Xcode 4.4 i get an error ("Permission Denied") when I try to download the Documents from the sandbox.
Is there anything new (maybe a new setting?) I have to change to obtain the Application Data from my device again?
Temporary fix is using itunes to get the files from the document folder.
In your .plist -> Information property list -> add:
UIFileSharingEnabled (YES)
Rebuild and go to itunes and get the files from document folder.
I am having the same problem and will give a little more information:
Even though Xcode gives the "Permission Denied" error, it does export two files into a xcappdata file and does not even export the "Documents" folder.
AppDataInfo.plist
com.apple.PeoplePicker.plist
Then I deleted the app and all data off the device and reinstalled it using Xcode. I exported the data after running the app and generating a log (log saved into the documents folder). This new log file was properly exported inside the "Documents" folder, but Xcode still generated the "Permission Denied" error.
After further running the app and generating logs, attempting to export the new data resulted in identical exports as the the first export after reinstall.
This bug appears to be fixed in Xcode 4.4.1
I have been temporarily mounting Xcode 4.3.3 from a disk image and using Organizer there. Not the best solution, but seems like an "okay" workaround.
UPDATE: seems to be fixed in Xcode 4.4.1
I'm seeing this problem also with Xcode 4.4, used iExplorer to get the files, someone else said PhoneView should should also work.
Sorry for late reply for this question. I thought its worth putting up if anyone comes across this situation. The best way to get hold of the data is by directly accessing application folder by using an Application called "iPhone Explorer" or "iExplorer" both are free and will let you directly access iOS device file structure and you can copy Documents folder from it.
Hope it helps. Thank you :)
I have created a sqlite database. and dragged it on to my projects resource folder.
In my project i am accessing a sqlite file from
/Users/user12/Library/Application Support/iPhone Simulator/4.3.2/Applications/1F219005-A4ED-4794-81FC-65EEF8D243EF/Documents/db.sqlite
I am not using the sqlite file that was added to the project. and my project is accessing the DB file from the above location.
So, now when i try to launch my application from a different mac i am unable to launch the application because the DB is not found in that path. So how could i solve this ?
note: i used FMDB.
My final objective is to give this application to my client and since he will be running the app on his iPhone, he should be able to access the sqlite file with no issue. So what changes should i make ?
Surely xcode in other machine will have a different path. Try to place the sqlite file at the app path created by xcode on the new machine.
EDIT:
To do what you've said in your comment i suggest to create an ad-hoc certificate. Then use xcode to create your archive.
But the path of your sqlite file should be in your main bundle.
ps: You need the UDIDs of your client iPhones to add the devices to the portal.
Having gone through all the steps of submitting my app to the iStore by the book (and other manuals around), I get a 'not so funny' response after uploading my binary:
'The binary you uploaded was invalid. Fat binaries require a MinimumOSVersion of at least 3.0'
Now, I set the device deplyment to be 2.2.1 and the Base SDK the same. My build SDK is 3.0 and I'm pretty sure I do not use anything which is in 3.0 but not in the 2.2.1 API (I built and ran on both and tested).
It might be nothing, or not - I do use XML parsing and some XML files in my application, again, I'm not even sure that it is connected ot the problem.
If you have any experience with that or have a clue it's be great,
Check the Info.plist of the binary that is produced. The file should have the following setting somewhere in it:
MinimumOSVersion XYZ
...where XYZ is the Deployment Target OS version you are trying to build for.
I have noticed in my own binaries that this line does not exist for binaries built for the iPhone Simulator. Given that, my suspicion is that you are trying to upload a binary built for the simulator instead of the device. Try changing the Active SDK to "iPhone Device 2.2.1" and submitting that binary to the App Store.
I had a similar issue and it was due to me zipping the file up (or trying to upload it) from a PC. I used 'compress' on the mac and uploaded using firefox for mac os and it worked fine.
This window becomes visible upon clicking on the root project name in the Xcode directory /groups tree, where you can change the:
! Deployment Target OS 8.1 and SDK declarations
Also, under the General tab is the Asset Catalog where the Icon migration and Launch screen file conversion takes place.