When you create a macOS app and keep the default menu, you automatically get an About dialog. This dialog shows basic info about the app.
If you want to add more information to this dialog there is no obvious way to do it. You need to start reading the Apple documentation to finally discover that it is actually quite simple.
[Read More]I am definitely not a fan of CocoaPods, I use Carthage in all of my projects. It is not ideal but I have a way of using it that works for me.
Recently I was faced with a problem that made me use CocoaPods but in a quite different way, just to build some frameworks to be used elsewhere without CocoaPods.
I use GRDB.swift to work with the database in iOS applications, especially because it support using SQLCipher to have the database encrypted. The current version 3.x has some problem when used by Xcode 10.2 and Swift 5 so using the latest 4.0 is recommend.
GRDB.swift never supported Carthage but there was always a way to make it work. I usually just needed to delete some of the shared schemes and run carthage build instead of carthage bootstrap. I was not able to make Carthage work with 4.0, mainly because the targets changed. There is no GRDBCipher target for use with SQLCipher anymore, just a podspec definition
s.subspec 'SQLCipher' do |ss|
ss.source_files = 'GRDB/**/*.swift', 'Support/*.h'
ss.framework = 'Foundation'
ss.dependency 'SQLCipher', '>= 3.4.0'
ss.xcconfig = {
'OTHER_SWIFT_FLAGS' => '$(inherited) -D SQLITE_HAS_CODEC -D GRDBCIPHER -D SQLITE_ENABLE_FTS5',
'OTHER_CFLAGS' => '$(inherited) -DSQLITE_HAS_CODEC -DGRDBCIPHER -DSQLITE_ENABLE_FTS5',
'GCC_PREPROCESSOR_DEFINITIONS' => '$(inherited) SQLITE_HAS_CODEC=1 GRDBCIPHER=1 SQLITE_ENABLE_FTS5=1'
}
endIt looks like only using CocoaPods and SwiftPM is now supported, there is not even an easy way to do manual installation.
I had to decide how to integrate 4.0 to my project in the best way possible.
When you use NSTableView in an macOS application, there is no direct way to know a specific NSTableViewCell was clicked by the user. In my Localization Editor project I wanted the user to be able to focus a NSTextField when clicking anywhere in the NSTableViewCell it is contained in, so I had to implement it myself.
I created a new delegate extending the NSTableViewDelegate with one additional method informing about a NSTableViewCell getting clicked
protocol NSTableViewClickableDelegate: NSTableViewDelegate {
func tableView(_ tableView: NSTableView, didClickRow row: Int, didClickColumn: Int)
}Then I added an extension to the NSTableView to compute the index of the clicked NSTableViewCell
extension NSTableView {
open override func mouseDown(with event: NSEvent) {
let localLocation = self.convert(event.locationInWindow, to: nil)
let clickedRow = self.row(at: localLocation)
let clickedColumn = self.column(at: localLocation)
super.mouseDown(with: event)
guard clickedRow >= 0, clickedColumn >= 0, let delegate = self.delegate as? NSTableViewClickableDelegate else {
return
}
delegate.tableView(self, didClickRow: clickedRow, didClickColumn: clickedColumn)
}
}To be able to use this extension you just need to implement NSTableViewClickableDelegate instead of NSTableViewDelegate and use the additional method it provides.
When I started working on my open-source Localization Editor, which is a macOS application, I encountered some things that were a bit strange compared to iOS development. One of those things is that copy & paste does not automatically work on a NSTextField.
To be exact, copy & paste works on a NSTextField as long as you do not delete the Edit menu from the standard Main menu. If you do that for some reason, you have to implement all the copy & paste functionality yourself.
The key to the implementation is overriding the performKeyEquivalent method and manually checking for cmd + c/v/x/z/a
final class EditableNSTextField: NSTextField {
private let commandKey = NSEvent.ModifierFlags.command.rawValue
private let commandShiftKey = NSEvent.ModifierFlags.command.rawValue | NSEvent.ModifierFlags.shift.rawValue
override func performKeyEquivalent(with event: NSEvent) -> Bool {
if event.type == NSEvent.EventType.keyDown {
if (event.modifierFlags.rawValue & NSEvent.ModifierFlags.deviceIndependentFlagsMask.rawValue) == commandKey {
switch event.charactersIgnoringModifiers! {
case "x":
if NSApp.sendAction(#selector(NSText.cut(_:)), to: nil, from: self) { return true }
case "c":
if NSApp.sendAction(#selector(NSText.copy(_:)), to: nil, from: self) { return true }
case "v":
if NSApp.sendAction(#selector(NSText.paste(_:)), to: nil, from: self) { return true }
case "z":
if NSApp.sendAction(Selector(("undo:")), to: nil, from: self) { return true }
case "a":
if NSApp.sendAction(#selector(NSResponder.selectAll(_:)), to: nil, from: self) { return true }
default:
break
}
} else if (event.modifierFlags.rawValue & NSEvent.ModifierFlags.deviceIndependentFlagsMask.rawValue) == commandShiftKey {
if event.charactersIgnoringModifiers == "Z" {
if NSApp.sendAction(Selector(("redo:")), to: nil, from: self) { return true }
}
}
}
return super.performKeyEquivalent(with: event)
}
}If you use a Hackintosh you need a good backup solution. The chance of something going wrong is a bit higher than when running macOS on an Apple computer. Any macOS update can theoretically break your installation, you can break you Clover setup by accident or you SSD might just die.
With a good backup solution you should be up and running in a few minutes after any of those problems occur. I tried a few solutions as my requirements changed.
First I decided to use CloneZilla and backup the whole macOS SSD into an image file on another HDD every week. In case of failure I would be able to restore the image file to the SSD or any new SSD and be back up and running in about 30 minutes. I basically use macOS only for work, so restoring an at most week old backup did not seem like a problem, I would then just do a git pull and all the important data would be back.
The backups worked fine, when I bought a bigger SSD for macOS and just restored the latest backup image to it and everything went fine. I had to remember to boot CloneZilla every week and do the backup, but that was not that much of a problem, it became a weekly ritual.
The problem is that requirements change over time, most of the time after problems you did not expect before.
CloneZilla works well with HFS+, can detect used and free space. This means it only backs up the used space, so the resulting image is not as big as your SSD and the process is fast. When you change the filesystem to APFS, for example when updating to Mojave this is no longer true. CloneZilla does not support APFS so it backs it up sector by sector, the resulting image is as big as the SSD and the process is quite slow.
One time I updated Clover and my Hackintosh did not boot, got stuck on some error message. The problem was that the Clover installer decided not to check OsxAptioFix3Drv-64.efi by default anymore and this module got deleted.
Doing a full restore from an image seemed like a waste of time when I just needed to restore one missing file. I used Clover on my Unibeast flash drive that I keep safe and booted the Hackintosh with it. This screwed up iMessage (different serial number). I then reinstalled Clover checking OsxAptioFix3Drv-64.efi, booted backed normally and fixed iMessage.
This made me realize that image based backups are not ideal for real world problems (you probably screw up your EFI or kexts more often that your SSD dies) and I got looking for some other solution.
I stumbled upon Carbon Copy Cloner; a backup tool that offers bootable backups for macOS. I bought another SSD for bootable backups and got to work.
Once you plug in the backup SSD, you need to format it to Mac OS Extended (Journaled). Do not just format the existing partition (if any already exists), format the whole drive.
[Read More]