I have recently started working with Apple Configurator to use features meant for Supervised devices.
In the Restrictions payload there's a key called autonomousSingleAppModePermittedAppIDs with the description below
Optional. Supervised only. If present, allows apps identified by the bundle IDs listed in the array to autonomously enter Single App Mode.
Availability: Available only in iOS 7.0 and later.
I tried sending this key in the restrictions payload with a couple of app identifiers, but could not find any change in the behaviour of the OS. The Guided Access allowed all apps to enter into the SingleApp mode.
What I understand (and expect) from this is we can allow a list of apps to enter Guided Access (Single App) mode and no other app except the allowed ones will be visible on the device. Can you help me understand the things I'm missing or misunderstanding.
I believe the idea of this key that application itself can request a guided mode (vs guided mode triggered by a user or AppLock profile).
I believe application should use following API to request a guided mode:
void UIAccessibilityRequestGuidedAccessSession(BOOL enable, void(^completionHandler)(BOOL didSucceed));
In the case, if it's not on this list, this request will be rejected.
P.S. A device needs to be supervised.
Apple Configurator doesn't have the settings to manage "autonomousSingleAppModePermittedAppIDs"
Instead I decided to manually edit a profile and include the appropriate XML with the above key (referenced from here).
Upon trying to install the modified profile, Configurator explicitly says "The profile must be installed by a Mobile Device Management server."
The profile will install fine if this key/value pair is removed.
It looks like you MUST use an MDM to install a profile for use with Autonomous Single App Mode.
I was not able to find autonomousSingleAppModePermittedAppIDs in Apple Configurator. Looks like need to buy Apple Profile Manager (OS X Server in the App Store) for this which costs about $20.
Related
My Use case :
I have an automation framework for Mac that launches 2 instances of the same app ( same bundle id) available at different locations to simulate two endpoint cases for media calls. With introduction of Mojave permissions, when I grant permission( camera , mic & accessibility) for one instance of the app, the other instance doesn't have the same permissions.
Since the bundle id is same, is it not that providing permission for the app is carried over to both instances?
I tried pushing a system profile to provide permissions but that doesn't seem to work
Also added an apple script to continuously check for permission pop-up and click ok to it. This works for mic and camera but not for accessibility. Also when each instance is launched the permission would be asked again.
Is there a way to by default provide all access to the application by default without asking for any permission pop-ups?
Or is there any way to tweak something at the OS level to not ask for permissions at all ( behave same as <10.14) .. I tried disabling system integrity but that doesn't seems solve this issue
You need to code-sign all versions/copies of the app using the same identity.
When an app is not code-signed and the system needs to record its identity (as for permissions), it generates an ad hoc code signature. That signature, though, only matches that exact build of the app. Another copy of the app that is different in any code-signature-relevant way is not considered to have the same identity. In fact, it's likely to be considered "malicious" as it appears to have been tampered with.
If you code-sign your app with appropriate designated requirements, that enables the system to understand that two different versions of an app have the same identity and should share permissions. This is key to an app maintaining permissions through an upgrade to a new version, for example.
How do I setup the pubnub cocoa objective-c client api to NOT store anything on the keychain? Is it possible to store the keys on the Application Support folder instead? When I am using XCode the keychain messagebox modal appears three times even when I press the 'Always Allow' button. It stops for a while but then after a few minutes it asks me again the same way again.
I've checked on my side and it really requested password for each read from Keychain. Tried to find solution and after system reboot, tried again - it requested for password one or three times and then just keep working. As for now, there is no option to configure client without Keychain usage.
Earlier Keychain worked like well after single password input. Looks like one of system updates broke how system interact with developed applications.
Maybe it is somehow related to security and checking "Automatically manage signing" and specifying proper profiles will help you (I'm unable to check this, since Keychain gives me access w/o asking password now since I marked awlays).
Keychain used to store few fields: publish sequence number, uuid, and push token. It had been added to Keychain to survive application re-install.
We will review macOS Keychain usage and if it will be allowed, we will add ability to use file-based data storage (maybe by default for macOS).
I’m writing an app in React-Native and need some help concerning identifying the device after reinstalling the application.
What I need:
Get a unique device ID for every device for both Android and iOS.
The same ID should be returned even if the user uninstalls the application and installs it again.
The closest to this I’ve come over is the getUniqueID() method in react-native-device-info. However, a different ID will be returned on iOS if the app is reinstalled since the returned value for this method is related to the vendor.
Have a great day!
Well, if you need it due security purposes (e.g. so nobody is abusing your API or premium content), you are looking for Device Check / App Attestation for iOS and Google Safety Net for Android. By using these libs, you will get a unique device token (on iOS) or attestation (on Android).
When using iOS, you can take this token, and set up two bits on a server hosted directly in Apple by using your own server as a middle-man (as you should not do it directly, from the mobile app).
According to Apple: Apple records the bits for you and reports the bits back to you, but
you’re responsible for keeping track of what the bits mean. You’re
also responsible for determining when to reset the bits for a given
device; for example, when a user sells the device to someone else
Similarly, with Android - you just send attestation from device to server where it will be validated.
To use mentioned libs in React Native, you can either install corresponding libs:
https://github.com/dayitv89/react-native-ios11-devicecheck
https://github.com/rajivshah3/react-native-google-safetynet
plus you will need to implement verification part on your server
or if you are using Firebase libs (e.g. from rnfirebase.io), you can use AppCheck that uses SafetyNet and DeviceCheck / App Attestation underhood and comes also with easy server-side verification (also for non-Firebase resources).
If you need a solution that is focused on pushing data from server to client, you are looking for a push notification token.
Libs:
https://rnfirebase.io/messaging/usage
https://github.com/zo0r/react-native-push-notification
As this token can change over time (by design), you should implement few services that support that / or potentially re-architect your app.
Typically, tokens are stored under the user profile in your backend (or they are linked in some other way to the user that is using the device in the given time).
If you are looking for something else, I think it's not possible.
Don't worry MisseMask,
uniqueID's are always unique for your app bundle ID. There are two uniqueID's for each app.
That is one unique ID for debug version, and another one for release version. So please check your app by install it again and again with debug mode. now you get the same uniqueID. and do this process again with release build
for example:
Debug version uniqueID:
1st install - 3279dhsbqd9yrbceqiqbcv
2nd uninstall and install - 3279dhsbqd9yrbceqiqbcv
3, 4, 5, 6, .... - are same uniqueID
Release version uniqueID:
1st install - dsvfhdfgdf454tdsgsghetuh7j5
2 nd uninstall and install - dsvfhdfgdf454tdsgsghetuh7j5
3, 4, 5, 6, .... - are same uniqueID
I am developing an app (for like a year) and it works fine , when it comes to submitting to App Store -> all my problems started:
1)The app store would me to make my app to run in a sandbox(Why Apple ? Why !?).
It took like 2 days to understand why just toggling "ON" in capabilities doesn't make it...
etc ... in the end I somehow managed to convince my app to run in sandbox.
2)now the app passing the validation fine and can be submitted to the bloody App Store
However when I checked the app before the submitting I discovered that it simply don't want to work (running from Xcode or product).
It just crashes before it comes to `applicationDidFinishLaunchingWithOptions"
The crash itself is even more epic "thread1: EXC_BAD_INSTRUCTION (code=EXC_i386_INVOP, subdued = 0x0)"
and I see a lot of assembly lines -> from the comments inside the assembly I understood that the app tries to "Open" a sandbox , but then comes the bad instruction :( ud2
The stuck I see is:
_libseinit_initialize_once
0 _libsecinit_setup_secinitd_client
1 _libsecinit_initialize_once
2 _dispatch_client_callout
3 dispatch_once_f
4 libSystem_initializer
5 ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) ()
I think the rest are not relevant since they are all about some IMAGE loader :/
lately I ensured that removing the app sandbox key or setting it to NO Resolves my Issue but if I do so i getting back to issue number 1
so I kinda stuck with an egg and a turkey problem :(
maybe some 1 knows any interesting workaround or solution to submit the bloody app to the mighty app store ?
Sounds like what Apple document here:
OS X’s enforcement of container integrity impacts your development and
distribution cycle. This is because, in the course of creating and
distributing an app, the app is code signed using various signatures.
Here’s how the process works:
Before you create a project, you obtain three code signing
certificates from Apple: a development certificate, a distribution
certificate, and (optionally) a Developer ID certificate. (To learn
how to obtain these code signing certificates, read App Distribution
Guide.) When used in conjunction with the corresponding private keys
from your keychain, these certificates form three separate digital
identities. For development and testing, you sign your app with your
development identity. When you submit a version to the app store, you
use your distribution identity. If you are distributing a version
outside the app store, you use your Developer ID identity.
When the Mac App Store distributes your app, it is signed with an
Apple code signature. For testing and debugging, you may want to run
both versions of your app: the version you sign and the version Apple
signs. But OS X sees the Apple-signed version of your app as an
intruder and won’t allow it to launch: Its code signature does not
match the one expected by your app’s existing container.
If you try to run the Apple-signed version of your app, you get a
crash report containing a statement similar to this:
Exception Type: EXC_BAD_INSTRUCTION (SIGILL) The solution is to
adjust the access control list (ACL) on your app’s container to
recognize the Apple-signed version of your app. Specifically, you add
the designated code requirement of the Apple-signed version of your
app to the app container’s ACL.
I also had this problem, and although Droppy's answer was correct, it doesn't really resolve the problem (at least, not for me).
After messing around a bit, I found that the reason I had this problem is that, (although I had disabled keychain sharing in 'Capabilities' in Xcode's project editor) I still had a keychain value added. Removing this, or completely disabling all app capabilities (yes, including sandbox) will solve this problem.
Hopefully, this saves someone some time in the future.
I read about Worklight's Direct Update feature already. However, I still have some questions that would like to clarify:
Q1: Is it true that Apple allows Worklight Apps to be published to APP
Store even there is a direct update feature?
Q2: How will Apple review and monitor the Worklight Apps' content if
there is a huge change after the direct update? Or, Apple does not
worry about the cached web resource in the application, does it?
Q3: Is there any limitation or pre-condition about the direct update
for the web resource? For example, the major entries of html and js
script files must be existed... etc.
Q1: Is it true that Apple allows Worklight Apps to be published to APP Store even there is a direct update feature?
A1: There are existing Worklight customers that have submitted an application to the App Store and passed Apple's app submission process. For best results, make sure you use Worklight v5.0.6.1 or later.
Q2: How will Apple review and monitor the Worklight Apps' content if there is a huge change after the direct update? Or, Apple does not worry about the cached web resource in the application, does it?
A2: Apple only reviews app submissions to the App Store and whether or not they follow their guidelines. They do not review future updates to the application (as long as it was not re-submitted), for example in the form of a Direct Update unless there are some extra-ordinary circumstances (like inappropriate content that was discovered afterwards, for example...)
Q3: Is there any limitation or pre-condition about the direct update for the web resource? For example, the major entries of html and js script files must be existed... etc.
A3: I am not entirely sure I understand the question. There is no limitation in Direct Update - this feature replaces the existing web resources of an application with new ones. The only thing I can think of is that both the Worklight Studio (that the app was created on) and Worklight Server (that the app lives on) must be of the same version number.
An update.
Apple now allows code updates if you use a webview
3.3.2 An Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts,
code and interpreters are packaged in the Application and not
downloaded. The only exception to the foregoing is scripts and code
downloaded and run by Apple's built- in WebKit framework, provided
that such scripts and code do not change the primary purpose of the
Application by providing features or functionality that are
inconsistent with the intended and advertised purpose of the
Application as submitted to the App Store.