How To Write IRC: Part 6August 26, 2017 -
This is a continuation of the article published yesterday: How To Write IRC: Part 5
After all this work, it was time to make the actual framework. I started by making a new project with the Cocoa Framework template and copying over the important files from my demo project.
Next, I setup support for Carthage for people to bring this into their own apps. I could support Cocoapods as well, but I don't especially care, so I left that for someone to submit a pull request to add. Supporting Carthage was fairly straightforward, I followed the directions on their front page without much of an issue. One minor thing I ran into: because I was developing this using the latest Xcode Beta and not normal Xcode, I needed to use
xcode-select to tell command-line xcodebuild (which Carthage uses) to use my beta version of Xcode instead of the default. I don't think in the end I used anything special to Swift 4 that would require the beta, but I'm too cool to go back now and support older versions, Swift 4 will be finalized soon enough.
The next step in making a framework is important, but often skipped: documentation. You should provide at least a basic usage guide so that people have any clue how to use your library. Nobody wants to go fishing around in your code to figure it out unless they absolutely have to. Initially, they just want to be able to pull in your library and try it out. After writing documentation, I pushed my code to Github in a new repo. You can find it here. I also needed to create a release tag for versioning purposes so I start at v1.0. Sure this wasn't a super-complete implementation of everything possible with IRC, but it was enough to use for demos which was my intent. I don't like the idea of starting with version "0.1" or some such, that implies it isn't usable yet. The last step to building a framework was to update the demo app to use the framework. So I go in, delete all the IRC code that now exists in a framework, including tests, and instead import my new framework.
It was a good thing I decided to do this because it uncovered a massive flaw in my plans! I forgot that, since my IRC code is bundled into a framework, I must mark all my classes public if I want them to be visible outside the framework. Whoops! I decided to only make the user, channel, and server objects (along with their delegate protocols) public. A developer using this framework shouldn't need to use the input parser directly or any of the enums I made to handle the parsed input. With these changes, I commit again and replace the original 1.0 release to this new one. Normally you might want to issue this as a bugfix release or something, but since I published the initial release literally 5 minutes before and I'm not very popular, I know that nobody has downloaded that original release yet. There's a certain safety in not being popular at all.
And that's it. I wrote some code with tests and published it as a framework people can play with. Fun times had by all.