I'm modernizing and sandboxing an old Cocoa utility and considering approaches. The app lives in the menu bar and works in the background, but shows a Dock icon and a configuration window when the icon is clicked.
There are two approaches:
A. A single binary with LSUIElement=YES, using TransformProcessType to show and hide the dock icon as necessary.
B. A helper tool performs the actual app functionality, manages the menu icon and always runs in LSUIElement mode in background. The main app presents the configuration UI and is only launched when necessary.
The app currently does A. I've noticed that many long-running utility apps have separate helper binaries and basically do B. Examples on my Mac include Paste Helper, TimingHelper, Discord Helper, CCC Helper (for Carbon Copy Cloner), 1Password Extension Helper.
I understand that having a separate helper app is conceptually more pure and potentially allows for better separation of sandbox privileges, but it's also harder to implement, so I doubt that's the sole reason why all these apps opted to have a separate helper binary.
So:
What are the pros and cons of A and B, i.e. why do some choose B over A? Is it required to get some functionality these days?
Is it even possible to have a helper tool outlive the main app in a sandboxed Mac App Store app?
What API does one use to make such a helper? The old-style authorisation APIs seem deprecated, and XPC does not seem like it allows a helper app to launch at startup (and even outliving the main app may be hacky)?
I suspect the reason so many developers choose option B is because this arrangement is now baked into macOS via the "Login Items" facility.
In a nutshell, your main application embeds a second (helper) app and that app is configured as a "Login Item". macOS detects this and automatically adds your helper app to the user's login items. You can control this, programmatically, using SMLoginItemSetEnabled(...).
You end up with a regular app users are familiar with, and a helper app that automatically starts at login and can run in the background. I'm also pretty sure this includes a free XPC connection you can take advantage of.
Read all about it in the Adding Login Items section of the infamous Daemons and Services Programming Guide.
I've never done this myself (I currently install background apps as user agents, which I can do because I don't have a sandboxed app), but I did research it for another project and I know a lot of apps do this.
One disadvantage of option A (based on user feedback from my own apps) is that the main app won't act like a regular app. Using the A approach, your users either can't quit the app (because it will need to automatically restart) or you need a way to hide it in the dock, and then there's no (obvious) way to launch it again. It just gets confusing. If you do let your users quit the app, then the background functionality goes away, and that creates other problems.
Related
I've created a mac application. Runs great, all is good. However, I want to be able to have multiple instance of the same app. So, all my app has is one window and a view controller. I would like to allow the user to go to File -> new and instantiate a new fresh instance of the already opened window, so the user can have as many open at the same time and have each handle its own options.
I hope this makes sense. I am new to Mac Development. I am not sure how to go about this. Any pointers?
However, I want to be able to have multiple instance of the same app.
Don't. This is not an idiomatic behavior for macOS applications; there should only be one instance of an application open at a time.
If you want to allow the user to open multiple windows (like you can in TextEdit, for instance), what you are describing is typically known as a document-based application. Read Apple's documentation for details on how to create one, and what it will do for you.
I've read lots of articles about creating helper tools as LSUIElement and then have them added to LoginItems using SMLoginItemSetEnabled.
What I want to know is, am I allowed to add the main app to LoginItems instead of creating a helper? (And the main app run as a LSUIElement shows in the status bar.)
Since the features were all in the helper and the main app is just a launcher, due to sandbox I can't really validate the receipt within the helper, so I can't prevent people from start the helper directly.
And if it's allowed (I have seem such app but not sure how they did it, such as "Flamingo"), how to add it to LoginItems without have it should down when toggle the settings? As SMLoginItemSetEnabled will terminate the app when pass false.
Thanks.
I have a status bar application from which I can launch a helper application for preferences. All preferences are stored in NSUserDefaults in the helper app and are read using addSuiteNamed: in the main app.
I would like to notify the main app when preferences are changed in the helper app. What is the best way to do this?
I have tried using NSDistributedNotificationCenter but this is too slow and not very reliable.
RMSharedPreferences by Realmac Software seems to be what I was looking for. It allows communicating between multiple apps and it is very easy to setup and seems to be way more reliable than NSDistributedNotificationCenter.
Is there a way to make my winRT application as a screen saver in xaml?
As Jerry says, there's no straightforward way to make a Windows Store app screensaver. However, there's a roundabout solution that might work for you on Windows 8, but not Windows RT. I have it nearly working. I'll share what I have so far.
A screensaver is just an executable with a .scr extension that's kept in C:\Windows\System32. For example, look at C:\Windows\System32\Bubbles.scr. The solution I have in mind is to create a .scr screensaver whose only purpose is to launch your Windows Store application, which you say will use XAML.
You can't launch a Windows Store app from the command line directly, so you'll create a launcher app. Take a look at a blog post called Automating the testing of Windows 8 apps by Ashwin Needamangala. Partway down the article, look for the section called Automating the activation of your app. It contains a sample C++ application which can launch Windows Store apps in the following way:
C:>Win8AppLaunch.exe Microsoft.BingNews_8wekyb3d8bbwe!AppexNews
The sample launcher on that page needs to be modified, but before you do that just copy the code into a C++ console app:
You're almost ready to test it out from the command line, but you need to specify the name of the app as an AppUserModelId. The details are in Ashwin's post, but to paraphrase you first want to allow the execution of PowerShell scripts on your system with:
PS C:> Set-ExecutionPolicy AllSigned
Then run this PowerShell script:
$installedapps = get-AppxPackage
foreach ($app in $installedapps)
{
foreach ($id in (Get-AppxPackageManifest $app).package.applications.application.id)
{
$app.packagefamilyname + "!" + $id
}
}
You might like running it in the Windows PowerShell ISE. It's pretty slick. Find the AppUserModelId of your app and then test Win8AppLaunch.exe from the command line, as shown above. This should launch your Windows Store app from command line.
Next, modify the C++ launcher to hard-code the AppUserModelId of your application instead of parsing it from a command line argument. I created a Gist of this. The important part is the line where I declare myApp.
Build the new executable, rename it MyScreenSaver.scr and put it in C:\Windows\System32. It will then appear in the Screen Saver Settings Control Panel. You can preview the screensaver there, and it works. However, if you wait for the screensaver to launch, it will briefly bring up a console window and never fully launch. I'm not sure why. I tried disabling the creation of the console window by switching the project to a Windows app, but that didn't help. You can try that yourself by changing Properties | Configuration | Linker | System | SubSystem to WINDOWS. It's a little more involved, as you'll also need to change the entry point from _tMain to _tWinMain. Contact me through my blog if you want the details. My StackOverflow profile lists it.
At this point it's almost fully working. You might try starting with a blank C++ screensaver that you know works, and then copy in the above code. If I get more time, maybe I'll try this myself.
Cool idea. But, no.
If you want your application to really do something for Windows other than run as a simple app, then you write an extension app. Here's the official word:
Extensions An extension is like an agreement between an app and Windows. Extensions lets app developers extend or customize standard Windows features primarily for use in their apps and potentially for use in other apps.
There are these types of extension apps right now:
Account picture provider (extension)
When users decide to change their account picture, they can either select an existing picture or use an app to take a new one. If your app can take pictures, you can use this extension to have Windows list your app in the Account Picture Settings control panel. From there, users can select it to create a new account picture. For more info about this extension, see the UserInformation reference topic. You can also check out our Account picture name sample.
AutoPlay (extension)
When the user connects a device to a computer, Windows fires an AutoPlay event. This extension enables your app to be listed as an AutoPlay choice for the one or more AutoPlay events.
Background tasks (extension)
Apps can use background tasks to run app code even when the app is suspended. Background tasks are intended for small work items that require no interaction with the user.
Camera settings (extension)
Your app can provide a custom user interface for selecting camera options and choosing effects when a camera is used to capture photos or video. For more info about this extension, see Developing Windows Store device apps for cameras.
Contact picker (extension)
This extension enables your app to register to provide contact data. Your app is included in the list of apps that Windows displays whenever the user needs access to their contacts.
For more info about this extension, see the Windows.ApplicationModel.Contacts.Provider reference topic. You can also check out Managing user contacts.
File activation (extension)
Files that have the same file name extension are of the same file type. Your app can use existing, well known file types, such as .txt, or create a new file type. The file activation extension enables you to define a new file type or register to handle a file type.
Game Explorer (extension)
Your app can register with Windows as a game. To do this, you must create a Game Definition File (GDF), build it as a binary resource in your app, and declare that resource in the package manifest.
Print task settings (extension)
You can design an app that displays a custom print-related user interface and communicates directly with a print device. When you highlight the features that are specific to a particular make and model of print device, you can provide a richer, more enhanced user experience.
Protocol activation (extension)
Your app can use existing protocols for communication, such as mailto, or create a custom protocol. The protocol activation extension enables you to define a custom protocol or register to handle an existing protocol.
SSL/certificates (extension)
Digital certificates are used to authenticate one entity to another. For example, certificates are often used to authenticate a user to web services over SSL. This extension enables you to install a digital certificate with your app.
cite: http://msdn.microsoft.com/en-us/library/windows/apps/hh464906.aspx
Unfortunately, nothing has to do with screen savers. The technical reason, at this time, you cannot write a Windows 8 app that functions as a screensaver is because Windows 8 apps are fundamentally tied to run inside the WinRT execution environment. That shell does not extend out past the Start menu in this current version of Windows. So, there's no way to execute outside - like as a screen saver. Screen savers are still built the "old fashion way".
I want to develop a application like http://orbicule.com/undercover/ or
http://hiddenapp.com/.
I know how I could do that for windows but I have totally no clue, what kind
of approach I would need for mac os x, cocoa/xcode.
Is there anything I should be aware of when building applicatons / background services
with no GUI for mac os x?
The service will post data to the webpage with the usual data like geo location & IP
information about the machine so it should be able to access the internet too.
Please lead me to the right path.
It's fairly straightforward.
Go to:
Information Property List Key Reference
http://developer.apple.com/library/ios/#documentation/general/Reference/InfoPlistKeyReference/Introduction/Introduction.html
in the Launch Services Keys, you will see one called "LSBackgroundOnly" simply define this in your Info.plist and set it to true.
<key>LSBackgroundOnly</key>
<true/>
From the documentation:
LSBackgroundOnly (Boolean - Mac OS X)
specifies whether this application
runs only in the background. If this
key exists and is set to “1”, Launch
Services runs the application in the
background only. You can use this key
to create faceless background
applications. You should also use this
key if your application uses
higher-level frameworks that connect
to the window server, but are not
intended to be visible to users.
Background applications must be
compiled as Mach-O executables. This
option is not available for CFM
applications.
Your application will be a background application.
Give System Startup Programming Topics a read. Create a command line tool project, not a Cocoa Application nor a Cocoa Document-Based application. To provide a GUI to interface with it you'll want to use a separate application (ideally one you don't have to install with the "hidden" app, since you seem not to want it to be easily discoverable).
With the exception of AppKit (UI) stuff, the rest of the basic Cocoa frameworks is still available to you via the command line. This means you'd write the main logic of your app (the non-GUI parts) the same as you would otherwise.