The default behaviour of XCode Cocoa Mac OS app is that when the window close button is it, it simply closes the app window. However the App doesn’t quit.
Which means that the app is still running and when we try launching it again, nothing will happen. We have to manually quit the app (e.g. by right clicking the app icon in dock and clicking quit) to close it properly.
In this tutorial we will learn how to make xcode swift cocoa app quit on windows close event, making swift terminate application when window closes instead of just hiding the active window.
In this episode we build an app to app to track Dad Jokes, first using navigation views and lists, then porting it to macOS using Catalyst and native macOS S. If you run macOS, you’re going to run into issues when a misbehaving app like Safari eats up system resources while refusing to quit the normal way. On iOS, it’s easy to force-quit any app iPhone or iPad app, and watchOS also provides a similar shortcut for purging an unresponsive task from its memory.
How to quit cocoa app when window close using swift
This code is tested on xcode 8.2 with swift 3.0.1 on macbook pro running MacOS Sierra 10.12.2.
Handing it needs three steps:
Lets see them in detail.
1. Conform toNSWindowDelegate in your ViewController class
First step is to make ourViewController class conform to the NSWindowDelegate. To do this, simply add NSWindowDelegate to the class declaration like this:
Yes we can add as many protocols that we want to, separated by commas, just for info if you didn’t know already.
2. Override viewDidAppear method
We need to override the default viewDidAppear method and add our code to it. It should look like this:
Why aren’t we using viewDidLoad instead of viewDidAppear? Because self.view.window isn’t defined in viewDidLoad probably in some situations (or all?).
3. Add windowShouldClose method
This method will be called when the window is about to be closed. First lets see the swift code then discuss it. We simply need to add this code:
Note:
Xcode might give you a warning (not an error) at this point, however ignore this error and don’t do any of the suggested changes by xode or our code won’t work. Which means:
Also note that (_sender: Any) is required otherwise it wont work.
Return isn’t required as the application is going to terminate anyway. However if you do add the return, do it like this and then possibly return something too. (I would suggest to simply leave the return part unless you know what you’re doing)
Also, we can replace NSApplication.shared().terminate(self) with exit(0) too, however I don’t recommend that.
Explanation of the code:
We can use windowWillClose instead of windowShouldClose too. Which one to use? Well both should work fine, unless your app does something specific on both events.
Difference between windowWillClose and windowShouldClose is:
Also note, that the sender can be both Any or NSWindowDelegate too.
Swift Macos Quit App MacComplete code
The complete code (excluding your own and other required code of the class) will look like this:
Note: The code above has to be added. Any other code of your class should still remain there and work as it needs to.
I hope this will help you understand how to make your applications close properly when the windows close button is clicked in your xcode cocoa app, using swift 3.0.1 code. If you have any queries or corrections and improvements to this tutorial, please let me know through comments.
You might also like
With Mac Catalyst and SwiftUI support for macOS, Apple has been pushing new tools to the community for the past couple years to create new services on Mac computers. Does it mean you should do too? Here are couple things to consider first.
During WWDC 2019, Apple released Mac Catalyst for developers to turn their iPad version compatible with Mac. The same year, SwiftUI was released and introduced a whole new world of possibilities.
I don’t think it’s random that Apple pushed so many new tools to help build apps for Mac. After all, its App Store is a multi billion dollar business. Wouldn’t it be great to consolidate its macOS version by attracting the developer community with great tools? That might just work.
So back to us. Assuming we have an existing mobile app, should we consider creating a macOS version to get to this potentially new users?
As usual, I think it depends. Let’s see what to consider before rushing anything.
Swift Macos Quit App SyncUser ExperienceSwift Macos Quit App Windows 10
First thing to consider is the User Experience. By creating a macOS app, do we enhance anything in the existing service? Do we actually take advantage of using a native device rather than a web platform?
I believe it’s important to create an app that feels home on Mac. Like any other software on Apple device, users are used to a “first class” experience, so it’s important to move towards the same goal.
MovieSwiftUI has been a reference since the early days of SwiftUI of how to successfully develop a multi-platform app.
Nobody wants a half baked app that takes too much memory or that hardly resize its window, poorly handled shortcuts or Mac behaviors like the classic drag & drop.
If you already have a website that already does it all and you can’t see a real improvement in the User Experience, then maybe it’s not the best fit to start this adventure.
If, on the other hand, you feel that having access to a powerful computer can really make a difference to your app, like a picture/video editing tool, then go for it! Netflix would be another great candidate for a native macOS app.
Development Cost
Shared code across platforms doesn’t mean new platform comes at no cost.
“Great, we can reuse code all our code, right?”.
Definitely not. Journaling app mac password.
If your project wasn’t optimized and designed for it, it’s hard work to get it ready for multi-platform. And once you are there and release a macOS version, remember it’s as much work you’ll need to support and maintain over time.
Some businesses removed their support to iPad for the same reasons: they didn’t have the capacity to support it in the long term and the effort for it was higher than the reward. Creating a poor tablet experience causes frustration to their developers as well their customers. It turns out to be a lose lose situation.
So if you choose to move forward, make sure you can go the distance.
Swift Macos AppApp Usage
If it’s common for iOS users to browse the App Store and install / uninstall apps, I believe the same behavior is not true for Mac.
You can ask yourself the same question. Do you remember when was the last time you installed an app on your iPhone? How about your laptop? For me, it has easily been weeks or months.
If you managed to get your user installing your macOS app, chances are it will be for a long time. I don’t think many users clear their programs on weekly or monthly basis.
In short, mac users could be there for the long term (or longer than iOS one), so let’s make their first experience the best one.
RedditOS has been a great alternative to Reddit website.
New Market
Finally, before rushing into the design and development of a macOS app, it might be interesting to look into platform usage breakdown. Would it be new users joining or existing users moving from another platform (iOS, Android or Web potentially)?
Mac app delete applications. It’s important to understand it as it could also backfire and split existing usage into 2 platforms rather than creating new one.
In conclusion, bringing your app to macOS can be really exciting but it can come with complexity and cost, so it’s good to get ready for it.
Macos App Store
Let’s also remember ourselves that when the first iOS SDK was release in 2008, every company wanted to turn their website into app, as irrelevant as it could be.
Macos App Download
Today, I think we need to be more careful about these decisions and make sure if you move forward, it’s acknowledging your user’s expectation.
Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |