#hireme I'm an iOS/macOS developer with more than 10+ years of software development experience (in different development areas). I've ~3 years of experience in #AppKit, #UIKit, and #SwiftUI, #uidesign and system design. I appreciate collaboration and team work (in the real sense).
I'm open for both remote and onsite (hybrid) positions. I would appreciate if you could boost this post, I'm in critical need for a job at the moment.
Anyone use https://github.com/tuist/tuist in lieu of a native .xcodeproj? I mainly ask because git merge flows are painful with the latter format. Too many conflicts that result from irrelevant internals.
Here it is: A comprehensive look at NSItemProvider: what it does, how it works, and how to use it properly. I want this to be a one-stop-shop reference for anyone using this class in their projects.
NSItemProvider is a key class in iOS and Mac Catalyst, used in everything from Drag and Drop, to Pasteboard, share sheet, and beyond. Understanding how this class works will help you make better apps and gain insight into what the system does for you.
Please read the post, and send me feedback. Share it with your iOS developer friends. Let me know what you think!
Did I just spend multiple days on centering toolbar items? Y-yeah. Turns out in an AppKit toolbar, either all items have a label, or none of them does. Setting an empty label leaves the view weirdly positioned.
The code is a big hack: it mutates AppKit-created constraints, finding them by item/attribute pairs. And to make sure the tweak re-runs whenever the toolbar item updates, I had to swizzle a method on the NSToolbarItemViewer private class.
I'm having way too much fun with SwiftUI for #Macintosh. This is really coming along and already has more features than the AppKit version.
#SwiftUI does get kinda slow though... I notice the animations are a bit choppier than under #AppKit. When I use the "Debug View Hierarchy" feature in #Xcode, I notice SwiftUI has far more layers than a standard AppKit app does... not sure if this contributes to the slowness.
I'm sure will only continue to improve it though.
The more I compare TextEdit (NSTextView) with Xcode text view (editor) in terms of text interaction, the more differencea I notice. Usually Xcode editor has it wrong (sometimes slightly, sometimes significantly)
I compare behavior in 3,4 editors at once, and honestly sometimes it's hard to tell what is the right way as sometimes everyone and each handle a gesture/scenario differently
I would go even further that the “controllers” in the modern #AppKit / #UIKit world are even further away from the original conception of #MVC, and they’re hardly “controllers” in the original sense any more.
A Window Controller (AppKit) and View Controller (AppKit/UIKit) are tightly coupled to a specific Window or View, so much so that they are basically one and the same—no architectural advantage is lost by combining the Window Controller with its window; or the View Controller with its View.
I’ve always argued that the distinction between Views and View Controllers are quite arbitrary. VCs are used to house lots of functionality that regular Views don’t have—but you could have achieved the same by declaring a View subclass that conforms to the additional protocol, and doing away with the view-creation logic, couldn’t you?
IMO, the “MVC” in UIKit has no controller at all, when you think about it.
Just as in #AppKit, #SwiftUI also brings a new Inspector sidebar API and it works pretty great too! A tad bit more limited than what you can do in AppKit because well, AppKit is very mature and it's simply another style on NSSplitViewController (which is hella old) but yeah... pretty neat stuff, SwiftUI! :) #WWDC23
macOS Sonoma AppKit + SwiftUI introduced a new API for Split View Controllers where the trailing sidebar is can have an "inspector" style -- like Xcode. I just introduced it to my app with minimal change to adopt the new full-height look. This is what it looks like:
Ever-curious, I tried creating a new app w/ the traditional xib/AppDelegate architecture, but hosting a #SwiftUI view in the window.
Unfortunately, printing the window doesn't work out-of-the-box.
One of the cool things about #AppKit was that a window was printable with no extra code. Anything you were drawing in its contentView would show up in the default print implementation (which was also automatic because the window was responding to print messages in the Responder Chain).
I made a little extension method for getting an NSFont with a specific weight that uses an approximation of the systemFont’s new weight behavior. So you can do:
var regularFont: NSFont
let sameFontButBolder = regularFont.withWeight(weight: .semibold)