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.
Related
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.
My app setup is a basic new app with default viewController with the default classes for share extension on iOS 11.2.
The host AppDelegate class FinishedLaunching never gets called.
Just shows the launch screen and closes the app.
The sample Xamarin app provided also has the same issue.
Link to the sample app:
Share Extension sample
Any idea whats going wrong?
Do you want to open the app which you created with the share extension, when user clicks the share button to use this share extension? If so, this app should be called Containing App.
But unfortunately, there's no way to do this on iOS8.3+ except Today Extension. From this post we know that:
The intended approach for share extensions is that they handle all of
the necessary work themselves.
Also from the Apple documentation about extension:
An extension’s UI should be simple, restrained, and focused on
facilitating a single task.
Apple doesn't recommend us to open its containing app from extensions, actually it avoids that. If you want to retrieve data in containing app, you can set up an app group so that data can be shared between these two apps.
I'm trying to make an extremely simple note-taking app for OSX: one that can have multiple windows open and where I can quickly write down something. I don't want to store anything anywhere.
Most importantly: it should not nag about saving on quitting the app.
I'm nearly there, but I am stuck at turning off saving.
Any ideas if this is possible for a Document Based swift-app?
(using Swift and Xcode, complete NOOB at this)
There are different types of applications. You can specify this when you start a new project.
Disable "create document-based application" when you start a new project and it won't nag you about saving anything.
I have an app which needs to preserve data between times it runs. I had been using NSUserDefaults for this, but I've had a few users point this out to me: this causes different users to end up with different data, which isn't the way the app should work. It needs a single directory that it can read/write from regardless of which user is running it.
So, I need a non-user specific directory that a sandboxed mac app can read and write to.
Thanks!
(Oh, and if this directory is persistent between updates of my app, that'd be helpful, too!)
Quick barely related question: Is there a way to have a user modifiable resource file in a Mac App Store approved app? I don't want it to be modifiable via my app; I just want to make sure that users modifying it won't cause the system to kill the app for not matching a code signature hash or something.
I don't think that you will be able to read and write in a directory outside of the App Sandbox container without prompting the user to select it using Powerbox and saving a security-scoped bookmark (see App Sandbox Container Directory). From what I've gathered about App reviews lately, you won't even be able to specify a default in the open dialog if you elect to have the user choose the directory.
As for the second question, as I understand it any verification of code signatures is left to the developer. So while MAS apps have a _CodeSignature folder containing a plist with all the hashes of the resource, in my experiments changing them had no effect on app launch.
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.