When I try to add the item to Keychain i found this crash on iOS10
*** Assertion failure in -[KeychainItemWrapper writeToKeychain]
On iOS 9.3 I write the key in the keychain without problem
Thanks
It looks like a bug; a bug report has been filed, but there's a workaround. Just enable "Keychain Sharing" (under your app -> Capabilities tab in Xcode). See https://forums.developer.apple.com/thread/51071 for full background.
Edit: Ignore what I was rambling about... duh, forgot that under the project target's Capabilities tab I have also enabled Keychain sharing... Though still would like to get a deeper, more cogent answer.
So guess you can ignore this... but leaving here just in case you run into the privacy stuff (though that's another SO question which I'm sured has been answered elsewhere):
Yeah, I had the same problem (also with asking for location crashing)... looks like a change in iOS 10 regarding privacy and services. Strangely in my case adding the keys below this comment to the info.plist (or via Xcode you'll see them with "Privacy-*")
Funny thing is that suddenly keychain access worked just fine, even though none of these keys have anything to do with keychain access... I'm still digging more into that so I can provide a "real answer", but hopefully this can unblock you for now.
Here's what I added (note don't think you need all of them, but just to ensure my answer matches what I did):
<key>LSApplicationCategoryType</key>
<string></string>
<key>NSBluetoothPeripheralUsageDescription</key>
<string>health devices</string>
<key>NSRemindersUsageDescription</key>
<string>medication reminders</string>
<key>NSMicrophoneUsageDescription</key>
<string>calls</string>
<key>NSCameraUsageDescription</key>
<string>Allow Moonshot to use the camera (profile and calls)</string>
<key>NSMotionUsageDescription</key>
<string>Allow Moonshot to use motion to track activity</string>
<key>NSLocationUsageDescription</key>
<string>Allow Moonshot to use location to track activity</string>
<key>NSLocationAlwaysUsageDescription</key>
<string>Allow Moonshot to always use location (to track activity)</string>
<key>NSLocationWhenInUseUsageDescription</key>
<string>Allow Moonshot to use location while in use (to track activity)</string>
<key>CFBundleDevelopmentRegion</key>
Related
I am trying to submit my first catalyst app to the Mac App Store. I have setup the App Store information in iTunes Connect, and I have confirmed that the info.plist in app has the following key in it:
<key>LSApplicationCategory</key>
<string>public.app-category.business</string>
However when I go to upload to the app store I get the message that I need to add the LSApplicationCategory
ERROR ITMS-90242: "The product archive is invalid. The Info.plist must contain a LSApplicationCategoryType key, whose value is the UTI for a valid category. For more details, see "Submitting your Mac apps to the App Store"."
I have confirmed that both public.app-category.business is correct, and I have also tried using the value "Business". I get the same error message. Is there something else I need to look at?
The key which you are adding to .plist file is wrong. Add below key-value pair. Full list here.
<key>LSApplicationCategoryType</key>
<string>public.app-category.business</string>
slicerdicer's recommendation worked for me. To add some additional detail, you can also set the App Category by going to Project / Targets / General. It's the very first option.
I had sucsessfuly upload two apps using catalyst then the third failed with that error. I found this and seemed to work.
To the info.plist add App Catagory with what ever catagory your app fits. I used Productivity.
I was converting an iOS app to a Mac app, and I was updating the file info.plist, and it was not actually updating the overarching project.
I ended up having to go to the overarching project, under the left side TARGETS tab, I selected my app, went to the Info tab, and added the App Category there.
I want that after installing my app from an OTA the home button of the device will not work at all so that user is unable to come out from the App. My digging led me to following results
A) I got a way to disable home button by a "mobileconfig" profile but it needs to restart the device and user have to open my app just after booting, i want to do this without restarting with something like Private Frameworks on non-Jail-broken devices. I want to know is that possible for non-jail-break devices?
C) If it is not possible to disable home button with Private Frameworks, then is there any way to open an app just after booting the device?, since certain jailbreak apps/ processes are loaded upon startup.
[NOTE: I don't want to submit my app to iTunes.]
In iOS6, there's a feature called "Guided Access", which will allow device owners to lock users (like toddlers and school kids) into an app.
This explains the Guided Access for iOS 6 apps.
The official answer of this question is "you can not disable home button in ios devices it is os level architecture and your are not authorized for it."
You need to dig to operating system flow to make any changes which might be quiet tough.
well, if you change you sight though it than there is one open and simple solution for this in ios 6 known as Guided Access.
If you are able to jailbreak your device create a LaunchDaemon or use an existing one. The LaunchDaemon is a file in plist format that is called upon rebooting and starting your device. You will also need a file named open created by K3A
Download open from here
You will need to move open to /usr/bin/ or you can put it inside your app does not matter but set permissions to 0755 and root:wheel
Now on to the LaunchDaemons, they are stored here
/System/Library/LaunchDaemons
Here is an example.
Lets say you name the LaunchDaemon
com.gauravstomar.test.plist
Where it says com.bundle.identifier put your apps identifier you may also find it in your Info.plist inside of your apps directory where it says CFBundleIdentifier
Now inside the plist insert the following information
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.gauravstomar.test</string>
<key>ProgramArguments</key>
<array>
<string>open</string>
<string>com.bundle.identifier</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>StartInterval</key>
<integer>1</integer>
</dict>
</plist>
Label has to be the same name as the LaunchDaemon.plist excluding plist extension
ProgramArguments is what calls the file open and launches the app
RunAtLoad makes this plist launch upon reboot
StartInterval will make the LaunchDaemon.plist open back up after 1 second if the user exits the app, if the user is still in the app nothing will happened
Make sure the permissions for your LaunchDaemon is set to
0644 root:wheel
You can still use your mobileconfig so that the home button is disabled. Once assessment is complete you can disable the LaunchDaemon so that the app stops relaunching itself with the following command
launchctl unload/System/Library/LaunchDaemon/com.gauravstomar.plist
Let me know if you need any more help.
Without jailbreaking, the app is sandboxed. The app simply does not have access to mess with the home button. And you really shouldn't be messing with the home button.
In addition to "Guided Access", you can also make use of "Restrictions", which will allow you to disable everything accept opening your app. You can disable Apple specific apps including Safari, and prevent users from installing apps, deleting apps, making purchases, etc...
We have a number of iPod touches with a ticket scanning app we rent out to our customers. We make use of "Restrictions" to disable everything besides our app. The most helpful restriction thus far is preventing people from deleting apps - It's incredible how many people will accidentally delete an app, even after the warning prompt.
I've been looking at this page:
http://developer.apple.com/library/ios/#featuredarticles/iPhoneConfigurationProfileRef/Introduction/Introduction.html
for the configuration profile keys. I couldn't find one for the feature "Find My iPhone." Is there a key for that? If so what is it?
Sorry, but both Michael and titaniumdecoy are only partially correct. The "Find My iPhone" app is an app that helps you locate your iOS device if you have the settings set in your iCloud settings on the device.
I too would be interested in knowing if it is possible to push out a configuration profile (using IPCU) that has the "Find My iPhone" setting locked on even though it is technically an iCloud user settings.
I agree with #titaniumdecoy (and +1 to him).
If you are trying to push "Find My iPhone" onto all your iPhone(s) and you have more than just 3 or 4 iPhones to manage, maybe you can use something like Apple's iPhone Configuration Utility for Windows to install the app onto all the iPhones you have control over.
I have reread all the documentation and postings on Ad Hoc distribution and still have a problem. If I try 'wireless' distribution (with a .plist and .ipa file being downloaded using Safari) the app starts to download, the icon is drawn correctly and the name changes from 'Installing..' but when its about 90% complete I get an 'Unable to Download ...' alert.
If I use the iTunes method of transferring the app I get 'The app "xx" was not installed on the iPhone "xx" because the entitlements are not correct.'
Q1: I have read that you no longer need to separately add the .mobileprovision file because XCode (I am using 4.0.1) adds it to the bundle - is this true ?
Q2: when I 'download' the .mobileprovision in safari (on the iPhone) it merely displays it as text. Is this symptomatic of my problem or an irrelevancy ?
Q3: does this problem concern the Entitlements.plist ? I can't find any documentation from Apple or any blogs that relate to what I see when editing this file with XCode 4.0.1. If I follow the instructions (New->New File->Code Signing->Entitlements) I get a default file with only a 'Can be debugged' Key. I have tried setting this to NO, adding a get-task-allow Key (replacing the existing - presumably Can be debugged is the same key ?) adding my application-identifier, and adding an iPhone Entitlements Dictionary with the above two keys in (as per Apple's documentation).
Q4: what is the suicide rate amongst iPhone developers trying to get Entitlements and Code Signing working?
To cut down on suggestions I've seen for similar questions:
I do have Code Signing Entitlements set to my Entitlements.plist for Distribution and Release.
I have tried restarting XCode, rebuilding, archiving etc
I have tried restarting the iPhone
I have gone back to the iPhone
Update:In XCode 4.0.1 there is a menu option when the Entitlements.plist is being edited (Editor->Show Raw Keys and Values) which will toggle the key from 'Can be debugged' to 'get-task-allow'
The entitlements file should be:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>get-task-allow</key>
<false/>
<key>application-identifier</key>
<string>$(AppIdentifierPrefix)$(CFBundleIdentifier)</string>
<key>keychain-access-groups</key>
<array>
<string>$(AppIdentifierPrefix)$(CFBundleIdentifier)</string>
</array>
</dict>
</plist>
this works for wireless too.
Why on earth the default one doesn't have all this in is something only Apple can answer.
I can't see how to edit the raw text of a plist in Xcode so edited in TextEdit.
Code signing entitlements are no longer necessary for Ad Hoc builds in Xcode 4 - see details notes in Apple Technical Note TN2250
I just wrote a blog post outlining all the steps to successful ad hoc distributions in Xcode 4 which may be helpful. http://www.musicalgeometry.com/?p=1237
Entitlements.plist should be added in project and there should be only get-task-allow key inside it.
When debugging on device using developer profile, It should be checked
When building using Ad-Hoc or Distribution profile, It should be unchecked
Regarding Q4: If you like you can increase it by just doing... but I don't recommend it.
If you right click on the plist file in the project navigator, and select "Open As" then "Source Code", you can edit it as plain source.
Maybe they made a shorter version of Entitlements.plist in xcode4. The default Entitlements.plist does not contain the 'application-identifier' and the 'keychain-access-groups' keys, but if you change the value of the 'Can be debugged' key via the 'ASCII Property editor' it really changes the value of the 'get-task-allow' key in the background...
I tried setting the entitlements parameter "on" or "off", re-download my ad-hoc provisional that had been used for as long as I can remember, and tried hundreds of other combinations. None worked for me until...I went to the provisional portal and recreate a new provisional.
What really got me to stay up until 4:00AM and wasting hours of time that I did not have was how I created the ad hoc provisional. On Apple's iOS provisional Portal page, if you click on the "provisioning" on the left side bar, you will see 4 tabs: "development", "distribution", and the other two. I used to use my provisional created under the "development" tab and added all the test users' phone UUID. That had worked for me for years until the xCode 4 came along, and I was stupid enough to jump on board too fast. Apple engineers had always given me a surprise "mid-night" party every time xCode had an update. And they will wait long enough for me to forget this experience and release the next one.
The solution that worked for me was to create a provisional under the distribution tab. When you create a new provisional here, you have the option of selecting "ad hoc" as the "Distribution Method." After used this provisional on xCode project and target build setting, and turned off "can be debugged" on the entitlements, I then could install via iTunes or via OTA. I hope this tip might help someone save a few gray hair.
I am playing with idandersen's scifihifi-iphone code for keychain and came across the following behavior - I set the password using, say
[SFHFKeychainUtils storeUsername:#"User" andPassword:#"123"
forServiceName:#"TestService" updateExisting:YES error:&error];
Then delete test application from device and install it again - the previously set password appears to remain in keychain...
Is it the expected behavior? And is there a way to make sure that password I set will be deleted with the application?
Yes, this is the expected and correct behavior.
Some keychain items may be shared with other apps you control (that share the same keychain item access group).
You should just leave the info alone when your app is removed. You have no callback or method of removing the keychain items on deletion of your app.
Edit:
They finally reverted the behavior described in my answers, so until everybody move away from that range of versions, this should not happen anymore.
Unfortunately, this is not the case anymore. It has been changed since iOS 10.3.
This is an intentional change in iOS 10.3 to protect user privacy. Information that can identify a user should not be left on the device after the app that created it has been removed.
It has never been a part of the API contract that keychain items
created by an app would survive when the app is removed. This has
always been an implementation detail.
See the reference here.