As this question answered, I use AXIsProcessTrustedWithOptions with no option to test if my app has been enabled in the accessibility panel. If not, prompt the window to let users to enable it. There is button bound to this test call as well, so users don't need to close the UI and reopen it.
But sometimes, even after a user enables the app, AXIsProcessTrustedWithOptions still returns false. When I check the sqlite database, it shows my app as "kTCCServiceAccessibility|com.abc.def|0|1|1||". The first 1 digit indicates it has been allowed apparently. But the api call still returns false. At this point, if I close the UI, the app is unticked in the accessibility panel which causes a loop so users can never pass this step.
Another thing is this app is actually a version 2 of the previous app. But the user did replace the bundle with the v2 one. Not sure if this is related.
Any idea why this would happen?
NSDictionary *options = #{(id)kAXTrustedCheckOptionPrompt: #NO};
BOOL accessibilityEnabled = AXIsProcessTrustedWithOptions((CFDictionaryRef)options);
if (!accessibilityEnabled) {
NSString *urlString = #"x-apple.systempreferences:com.apple.preference.security?Privacy_Accessibility";
[[NSWorkspace sharedWorkspace] openURL:[NSURL URLWithString:urlString]];
}
Update: In Xcode, Signing & Capabilities, make sure you have selected a Team and Signing Certificate.
Original answer:
I experienced this when developing an app on macOS 10.14.5 in Xcode trying both AXIsProcessTrusted and AXIsProcessTrustedWithOptions .
After wasting a lot of time trying all sorts of things, including different options for AXIsProcessTrustedWithOptions, logging out/in, rebooting, praying, and crying, I eventually shut down my machine and powered it back on in frustration. Then it worked. Hopefully nobody else has this same experience.
Related
I’m trying to build a macOS utility that will allow me to programmatically change the order of full screen apps on my machine.
For example, let’s say the full screen apps on my machine are currently ordered as follows from left to right:
Chrome
iTerm
Xcode
I want to be able to call a method in AppKit to say something like “Move Xcode from full screen index 2 to index 0”. However, I can't identify an AppKit API that will help me do this.
NSScreen only gives the physical displays, not the full screen apps / spaces
NSApplication only gives the list of my app's windows
CGWindowListCopyWindowInfo looked promising, but it doesn't have information about the order of full screen apps. It also doesn't allow me to get a NSWindow object to have any hope of changing the order
Is what I'm trying to do even possible with AppKit?
Thank you!
Spaces (desktops and fullscreen apps are both just spaces) are a feature of the system Window Manager and only manageable by the user through the app Mission Control.
Of course, the Window Manager needs to expose an API for management, otherwise how would Mission Control interact with it? But that API is not public.
Reverse engineered headers for those private APIs can be found online, e.g.
https://github.com/NUIKit/CGSInternal
With those headers in place, you can write code like this:
#import "CGSInternal/CGSSpace.h"
CGSSpaceID activeSpace =
CGSGetActiveSpace(_CGSDefaultConnection());
NSLog(#"activeSpace: %zu", activeSpace);
CFArrayRef spaceArray =
CGSCopySpaces(_CGSDefaultConnection(), kCGSAllSpacesMask);
NSLog(#"allSpaces: %#", (__bridge id)spaceArray);
But the usual warnings apply here:
You cannot commit code using private APIs to Apple's App Store. There is no official documentation, all that is known about that API has been reversed engineered and may not always be correct. As the API is not public, Apple can change it at any time without any previous warning and thus your working code could break with every system update.
Any Idea what happened to the Setting's Custom URL Scheme on iOS 10?
Is Apple still giving acess to third-pary apps to launch iOS Settings from the app via URL Scheme on iOS10? The Old URL scheme are not working anymore!
None of the previous methods for launching the root "Settings" app on iOS 8+ were officially supported by Apple, so unfortunately we can't rely on them. It's also possible that apps that relied on the undocumented behaviors could be rejected during App Store review, even if others have been approved--even if the same app had been previously approved!
I've been unable to discover any workaround either, so it seems your choices are:
Open the app-specific URL (as detailed in many places, including #alvin-varghese 's answer above), and then ask the user to navigate backwards. (A terrible user experience, since it involves the user knowing to scroll up from the app list into the main settings sections.)
Use an instructional screen or alert in your app to educate users on how to find it themselves. (Not much better, but at least aren't dropped into an unfamiliar context with no waypoints.)
There doesn't seem to be an officially supported way of making this happen in iOS 10, and as you pointed out, it seems like the old ways (adding prefs scheme to your Info.plist file and using openURL(_:)) do not work any more.
From iOS 10 some of the things are changed,
So, for something like bluetooth you need to write below lines of code,
Swift 3.0 :
func openBluetoothSettings(){
let urlBTSet = URL(string: "App-Prefs:root=Bluetooth")
let objApp = UIApplication.shared
objApp.openURL(urlBTSet!)
}
Objective-c
-(void) openBluetoothSettings{
[[UIApplication sharedApplication] openURL:[NSURL URLWithString:#"App-Prefs:root=Bluetooth"]];
}
So, In above code what they have changed is string need to add "App-Prefs:root=Bluetooth" (This the example of opening bluetooth settings)
Don't forgot : 'Goto taget -> info -> URL Types -> Add "prefs" in URL Schemes'
Use this one, it works.
if let url = URL(string: UIApplicationOpenSettingsURLString) {
UIApplication.shared().open(url, options: [:], completionHandler: nil)
}
I have a sandboxed menubar application (no dock icon) that in it's preferences window allows the user to check a checkbox to have the app launch at login. I used to use the LSSharedFileList api, but as this is not allowed anymore for sandboxed apps, I've migrated to using SMLoginItemSetEnabled. What I've found is that although the app will launch at login, as expected, if I go back into the Preferences and uncheck and re-check the launch at login checkbox, I get a second instance of my menubar app launched.
Here's my helper app code (in its app delegate):
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
NSString * path = [[[[[[NSBundle mainBundle] bundlePath] stringByDeletingLastPathComponent]
stringByDeletingLastPathComponent]
stringByDeletingLastPathComponent]
stringByDeletingLastPathComponent];
[[NSWorkspace sharedWorkspace] launchApplication:path];
[NSApp terminate:nil];
}
Here is the code in my preferences window (main app):
- (IBAction)toggleLoginStatus:(NSButton*)sender{
if(!SMLoginItemSetEnabled((__bridge CFStringRef)#"myAppBundleIdentifier", (BOOL)[sender state])){
NSLog(#"Dagnabit!");
}
}
After the second instance launches, unchecking/re-checking the checkbox does not launch anymore instances. Does anyone have any idea what's going on?
Thanks
I've found the answer. None of the tutorials I looked at mentioned this, but in the docs for SMLoginItemEnabled says this:
The Boolean enabled state of the helper application. This value is
effective only for the currently logged in user. If true, the helper
application will be started immediately (and upon subsequent logins)
and kept running. If false, the helper application will no longer be
kept running.
So I'll have to check if the app is running already before allowing the helper to launch it.
I spent almost two days figuring out this. Finally dropped the idea to support launch at login.
Although it is just a case of Yes or no in the Front end, developer on the other hand has to spent huge amount of time(Adding a helper application and doing all those project settings in both the apps). The process in early days (before sandboxing)was pretty much simpler than it is now.
Also when the application is added to the 'launch at login' list, there is no way to verify because the application is not listed in system preferences -> users -> login items, as it was before sand boxing.
I am also facing a strange problem where I added helper app to the launch at login and then uninstalled the helper, but the activity monitor still shows helper app in the list, after each reboot.
Lets hope apple adds something like LaunchAtLoginController in coming future.
In my main app bundle I have supporting XPC service included. App is sandboxed and everything works quite fine, except that when I call [[NSUserDefaults standardUserDefault] setObject:forKey:] method and than - synchronize method from the XPC service app, preferences are not written and data cannot be retrieved next time I need it.
I didn't find anything related to this problem in Apple's documentation, except that the sandboxed app cannot access preferences of other apps. That's all right, I don't need it. XPC service has its own container in ~/Library/Containers, where it should be able to store its own data, I'd suppose. But obviously it's not the case for some reason.
I probably missed something, but cannot find what. Is there anything special which needs to be done (adding some entitlement or so) in order to make this work?
Thanks for any tips.
I believe you'll need to use Group Containers to share the preferences and I have achieved something similar (a non-UI LSUIElement app sharing preferences with its conventional Preferences app countpart) using RMSharedPreferences.
I have an app that I have been developing that can display sensitive user data.
When the user backgrounds the app, the OS appears to take a screenshot of the app as it was running, and displays it so when the user returns, their state is restored.
I am trying to prevent the user's information from being seen in this screenshot.
My initial idea was to display a Popup of my splash screen image, but it does not seem to render it in ApplicationDeactivated. Is there any other way you might accomplish this?
I am not sure you are analyzing this correctly. I don't see how the OS could take a screenshot of an app and use that to restore state. Also, if it was true that the OS did that, Tomb Stoning wouldn't be such a big issue in the requirements for an app in the submission process. A dev needs to handle grabbing and saving state on exit and reloading it on start-up again.
If you didn't code this tomb stoning, are you using a frameowrk that has built in support for this? You could disable the tombstoning so certain pieces of information are not stored, and in fact if this data is that sensitive you should make sure it isn't saved. But, if you save it make sure you encrypt it so nothing else could examine the saved state. Although, that shouldn't be possible on Win Phone as the OS is supposed to enforce the boundries between apps.
Received a response from Microsoft which indicates that this is not possible in the Mango SDK; it may be added into future releases of the platform.