A trivial Objective-C application for OS X Tiger

[cellularmitosis]

Heyo,

I'm an iOS developer by trade by am just starting down the path of learning to write mac apps for Tiger.

I've just gotten a first trivial app working: a units converter for inches and millimeters.

To build this yourself, open up Xcode 2.5, create a new project, and replace the contents of main.m with this: https://gist.github.com/cellularmitosis/15383aae4e95b633aff04ffc217f28fd

I've gotten this far with help from "Learning Cocoa with Objective-C": http://library.lol/main/DDC29798D8D8048E81CFCBAB1EDEF2AB

However, I've tried to do as much as possible programmatically, rather than relying on the WSYWIG Interface Builder.

 

[AphoticD]

Yes! I love this!

Welcome to the world of legacy Objective-C; no automatic reference counting, garbage collection, property / synthesize syntax, dot niceties, etc. Just old fashioned, long-winded Obj-C "v1.0" story-telling

I like your approach to writing the interface programmatically. This has appeal to me for portability across different versions of OS X / macOS. It is very likely your code will compile and run flawlessly on modern macOS (depending on some probable deprecated calls), and potentially earlier versions of OS X, like Puma (10.1), possibly even Cheetah, Mac OS X Dev Previews / Rhapsody releases - which might be pointless, but fun nonetheless.

Also, just for fun, attached is a little patch (which can be applied with `patch main.m units_patch1.patch`)

1. Fixed build warnings; Mainly, the old ObjC doesn't do read-aheads for interfaces (or forward class definitions), so I've moved `MainView` delcarations above `MainController`. The interface ordering issue would be avoided in a regular multi-file project as we would just be importing the .h interfaces in each .m (as needed).
2. Added `Private` interfaces for some internally called methods - as above, best to identify every selector call explicitly, even when not in the public interface to assist with your debugging and general housekeeping.
3. Commented out `_convertButton` references to remove this control from the interface.
4. Added `controlTextDidChange:` delegate method to listen to field changes and update the calculated view based on the last edited control.
5. Implemented simple decimal formatting to calculated output (i.e. "1.00")
6. Added `makeFirstResponder` and `setNextKeyView` methods for an "initial first responder" and bring in tab-key handling for changing the field focus.

Depending on when you entered iOS dev land, you might have been spared manual memory management, but in a pre-ARC/GC OS like Tiger, you'll want to ensure you get into the habit of always declaring a `dealloc` method for every class. Every time an object is released, it needs to be explicitly dismantled. i.e. each `alloc` / `retain` call must be matched with a `release` call for all non-primative properties of an object, so an object can recursively release all memory allocation / pointers.

For this, you'll want to familiarize yourself with the MallocDebug.app in "/Developer/Applications/Performance Tools/" to hunt for leaks. Try creating a leak and finding it to see how it works, and then testing this regularly as you flesh out your project.

​

 

[AphoticD]

I continued playing with this on older OS X build systems with some interesting results...

1. Build and run success on Panther 10.3.9 (Xcode 1.5). Just some minor text field sizing adjustments needed...

​

2. Build and run success on Jaguar 10.2.8 (running in a VM), pre-Xcode days, running Project Builder 2.1 from Apple Developer Tools December 2002. With the same text field sizing problem as under Panther.

​

3. Build failed on Puma 10.1.5 (Project Builder 1.1.1 - Apple Dev Tools Dec 2001). I tried digging around and couldn't figure out how to resolve the build errors...

​

4. So I went back to Tiger (Xcode 2.5) and set Mac OS Deployment Target to 10.1, then opened MainMenu.nib and File > Save As... to apply the "both" option for the pre-10.2 nib format. Built for "Release", copied the app bundle to the Puma VM and booted it back up again. This Tiger-built binary runs fine in Puma - and the text field size was correct.

​

This backwards compatibility gets harder to maintain as a project grows and other frameworks become required, but very cool to see this build from Tiger operating as expected in Puma and later without any changes to the codebase.

I am looking forward to seeing some new software ideas for our old hardware

 

[cellularmitosis]

Thanks so much AphoticD! Love to see this kind of contribution of expertise and compatibility exploration!

Do you have a history of desktop app development?

 

[Basic75]

I like your approach to writing the interface programmatically.

Programmatically generated user interfaces FTW! So glad Apple finally came around and created SwiftUI which makes this much nicer.

 

[AphoticD]

Thanks so much AphoticD! Love to see this kind of contribution of expertise and compatibility exploration!

Do you have a history of desktop app development?

You're welcome. It's great to see other developers show interest in legacy Mac OS X! It is a distinctly niche market, with zero financial incentive, so the work that gets done is purely a labor of love. An appreciation for older Mac hardware and our little community of tinkerers.

I don't have any solid desktop app development history, but I've written a few little tools here and there. I have been (slowly) working on some projects over the years which may eventually see the light of day

My professional history is in PHP since '01, and a regular role as a full-stack python/django developer keeps a roof over my head. I grabbed Cocoa by the reigns around 2017 after reading a number of books similar to the one you linked to and due to my interest in PowerPC, decided that any Obj-C project I approach will need to accommodate for Tiger (or at the very least, Leopard), so I found a few good books from that era and took on the approaches need to suit this wonderful "blunt edge" tech. (There are some insights on this topic at "Indie App development supporting PowerPC - Tiger or Leopard?" 2017)

With this in mind, what has brought you to want to develop for Tiger?