I wrote up a list of Apple (iOS, iPadOS, macOS) developer resources that are not directly from Apple. (Perhaps obviously, if you are wanting to get into developing for Apple’s platforms, developer.apple.com should probably be your first stop. This was written for someone who wanted links to other sites they should know about.)
I figured since I spent a bit of time compiling these, I’d re-post them here.
If you still feel like you’re getting a handle on Swift syntax, (or just want to brush up and/or clarify optionals), I highly recommend the Unwrap app. It was instrumental for me when I first started learning Swift.
Similarly (on the topic of Swift syntax) https://swiftly.dev/ is a nice “cheat sheet” style site with a lot of topics. (Made by a local dude!) He also made https://iosref.com/ which is another “cheat sheet” for various device-specific info.
All Apple developers should at least know there is a book on Swift Language syntax. Importantly, it’s updated for every new version, and you probably don’t want the version that’s currently in beta, so be aware of which one you’re reading. Also, that link is to the overall swift.org documentation, which has a bunch of other semi-interesting stuff listed too.
The Swift Package Index should probably be the first place you look for swift packages. Apple is a sponsor.
I read iOS Dev Weekly when it hits my inbox every Friday. Might not be as much beginner content there, but it’s definitely the main way I “keep up” on interesting blogs and viewpoints. The intro usually touches on any news I should be aware of as well. (The author is also the maintainer/founder of the Swift Package Index.)
Some blogs that I find myself on regularly (with really nice articles):
NSHipster is kind of in-between a blog and a reference site. It used to feel more important than it does to me now, but it’s still a really nice set of articles on some of the tricker topics you might encounter.
Hacking With Swift is a source of SO MANY good articles. I have this one on SF Symbols bookmarked, as it’s the definitive guide, IMO.
Swift By Sundel has a TON of excellent articles, and this link (the “Discover” tab) feels especially full of “required reading”. The author uses a very nice static site generator written in Swift, called Publish, on Github.
There are also a couple of relevant and local (to the Twin Cities, where I’m based, in Minnesota, USA) developer meetups:
SwiftMN is sort of the new-kid on the block. It obviously didn’t exist until Swift came about, and I was a late Swift convert (didn’t start using it until version 4), so I’ve only been to a few meetings. They have a mostly-dead slack also.
An open source example project (on GitHub it’s called SKHexGrid) for how to use a Swift package called hex-grid to generate hexagonal grids in various configurations.
An easy (and fun?!) way to draw hexagonal game boards.
Here’s some text from the newly re-worked About screen in the application:
There are a couple of other uses imagined for this application (outside of serving as a nice example for the HexGrid library):
You can configure and then Save images of hexagonal grids for use elsewhere. (For example, you might configure a grid for a board game played on a hexagonal grid, save it, then find it in your photos library and print it from there.)
So yeah, I think this first released in the app store back in March of this year (2023), although it had been on GitHub for almost a year now. I’m only just getting around to writing about it.
I guess I took a break from working on it for a while after Blither came out, but I’m back to thinking about it again, and I have a long list of things I want to make it do. You can see that list in the project README, but it’s a big bullet list that’s not really in any sort of order. I’ve written more about this below.
How did this come about?
While working on the app for Blither, I obviously needed to draw some hexagons on the screen. I had done this at least a few times previously, so of course the first thing I did was go look at my old code. The most extensive project with hexagons was of course Catchup (RIP earlier this year :sad:), but when I opened that up, I found that the hexagonal drawing was quite specific to the app, and not really all that extendible to different sizes or shapes of hexagonal grid.
I was disappointed by this revelation, and really wanted to use a library that could draw a multitude of different sized grids without too much extra effort. First-thing-first was to look to see whether such a thing already existed.
When making Catchup (and possibly even before!), I had been aware of the quite extensive tutorial on drawing hexagonal grids written by Amit Patel (Red Blob Games). That website is, as far as I can tell, the definitive guide on the subject. There are even links to other libraries, and it was there, in the Swift section, that I first found reference to the Swift package called hex-grid, that I ended up using for Blither.
So, while evaluating hex-grid, I still hadn’t quite decided what iOS framework/library I would use for drawing. Catchup uses UIKit, and I’ve used that professionally for over a decade, so it’s definitely the one I’m most familiar with. The only demo (at the time) for hex-grid was written in SwiftUI, which is Apple’s hot new declarative UI library, so I spent a bit of time with that, and realized the demo was quite limited. It really didn’t show off most of the features of the hex-grid library. (I’m also not sold on SwiftUI, but I did use it for all the menus in Blither as well as the menus in SKHexGrid, so I guess I’m coming around.)
I was starting to become familiar with hex-grid, and I decided to experiment with using SpriteKit , which is a 2D game engine/framework/library created by Apple. I’ve always avoided it because a) it’s proprietary to Apple, and b) UIKit is plenty capable of drawing a bunch of stuff really performantly, but at the same time, it has some nice capabilities, and I’d never used it before, so… why not?
Before long, I realized my “test” project (which I’d made specifically to easily switch around which grid is drawn) was a much better example of what hex-grid could do, and as I’d been in contact with the developers of that library a bit (mostly creating issues and asking them to add features for me), I showed it to them, and they promptly added it to the README.
One thing I’m really proud of creating for the application is all the different ways you can configure the coloring of the hexagons inside the grid. This is functionality that is unique to SKHexGrid, and not something that comes from the hex-grid project. (This is a candidate for pulling out of this project and contributing to that one, but it just sounds like a lot of work to me.) There are the following options for shading grid cells in the application:
grid shading types built into Hexagon Grid Generator
There is also a random color shading, but I didn’t picture that here. Each of these (aside from single and random color shadings) required their own algorithm, and were pretty fun to write. I only just thought of another shading type that might be fun, so I added it to the README.
What’s next for this project?
I did just yesterday submit the latest version (v.0.4.2) for app store review, so that should come out shortly. In it, I added the ability to draw and configure dots in the center of each hexagon, as well as lines between each of those center points. Just to illustrate, here are some example hexagons showing off those new features:
grids showing the new “center dots”, and “lines between center dots” features
As I said earlier, I have a long list of things I want to make the project do. I’ll just list a few of them, roughly in the order I want to work on them.
I really want to allow you to save the grid that you’ve customized, so the next time you load up the application you can see it again. This will let you toggle between different grids you’ve created, or save a “game in progress” that you’re playing with the app. But the serialization of colors makes it all a bit annoying. (SwiftUI uses a different object for colors than UIKit or SpriteKit, and it’s not serializable for some dumb reason.) I also think Apple’s new SwiftData framework is going to make syncing your serialized hexagon “save files” via iCloud a no-brainer to implement, and I’m kind of eager to play with that, so I might hold off on this feature until that is released along with the new iOS in the fall.
I think the next thing I’ll actually work on is showing coordinates not on the hexagons themselves, but as a sort of “key” along the side of the grid. This is common if you are doing any sort of annotation of your games, and should be highly configurable. Currently the cell (individual hexagon) coordinates are configurable, both in how they are displayed, as well as which coordinate “style” to use. But I’d like to be able to show the “axial” coordinate style both as two numbers (as it’s used in the library), as well as with a single number and an alphabetical character. Additionally, it would be nice to be able to “rotate” which side shows the coordinates, but I’m not yet sure how I would do that, so we’ll see.
After showing coordinates along the edges of the board, I’d also like to be able to show arbitrary colored borders for the entire grid. This is because one of the kinds of game most commonly played on hexagonal grids are connection games (like Hex). In connection games, the goal is to be the first player to have an unbroken group of your own pieces from one side of the board to the other. Or, as in The Game of Y, between 3 sides of a hexagonal board. Incidentally, showing the lines between hexes, makes the kind of board that is typical for The Game of Y possible, because (as in Go) you typically play your pieces on the intersections of lines, as opposed to inside the grid cells.
Anyway, if you’ve read this far, you are probably in the target market for this kind of application, and you should go download it now!
This post was written this morning in response to a post on dev.to asking about how self-taught programmers got their first jobs. I have told versions of my career path so many times that I think I wrote all of this in about 20 minutes. But I was thinking just now that I’m not sure I’ve written it all out like this before, so I’ll reproduce it here just for posterity.
I’ve been working in tech for well over 25 years. My career path has been long and winding, so I’ll try and give just the highlights here.
I did take a class in Basic in Jr. High school, and an Intro to C in college, but it was while I was in college, as an English major, that I began to teach myself html. This would have been 1996 or so, and I was president of our juggling club. I just wanted to update the webpage for the club, and that’s when I started to learn.
Key take-away for getting a job as a self-taught programmer: When you’re learning, be sure to pick a project or projects that you’re passionate about! It will be so much easier to complete them, and when you inevitably talk about them, that passion will only work in your favor.
Really, I just had small changes I wanted to make to that site. I needed to add myself to the list of “club officers”, and change the meeting times periodically.
Take-away 2: It’s much easier to make small changes to an existing project than to dive in to a large project “from scratch”.
Eventually, I started working on websites for various projects in the English department. One was a grant-funded research thing, and did not have html anywhere in the requirements, but I decided to post our findings / research as a webpage. That led to a very part-time job for another English professor, and that in-turn led to working at the student-run newspaper, writing html for a new “microsite” for the A&E section every week. That was almost certainly my first real job in tech, though it was a student position, and only 10-16 hours per week.
When my financial aid got screwed up at the end of 1999, I just dropped out and it only took me a month or two to land a full-time tech job (it was in the middle of the dot-com bubble). That job was “front-end” work, (html & javascript) and ~2 years later the company merged with another company, and 2004 or so I was the last person remaining from that original. By that time I knew I wanted to do back-end development, or what I considered “real programming”.
Take-away 3: Never stop learning. Try new things when given the opportunity, and you might find you enjoy some things more than others. You can totally shape your own career!
Once I started looking, I had a couple of job offers, but I ended up taking a job with some of my previous co-workers, and the idea was for me to do 50/50 front-end/back-end work. But I never really did much front-end work after that.
Take-away 4: Almost every job I’ve ever gotten has been because I knew someone, or was just in the right place at the right time.
Around 2007 I decided I could teach myself flash, just long enough to make my first video game. (I followed a tutorial on how to make Tetris, then modified it to have very different rules.) Around that time I started attending meetings of our local Twin Cities chapter of the IGDA, which I found very inspiring. I did my first public speaking, talking about my Flash game, and it seemed pretty well received!
Take-away 5: If you can, working on side projects is almost always rewarding. It’s especially important to get them to the point you’re not afraid to show them off, and put them in your portfolio or resume. (I do think portfolios are more important for folks who are self-taught than for folks with comp/sci degrees.)
Toward the end of 2008 I decided my next game would be for the iPhone. I spent a lot of nights and weekends, and I think I really leveled-up my programming working in Xcode and Objective-C. (I fell in love with strongly typed languages.) About 3 months later I released my first iPhone app in the store.
Around 2011 I’d been attending lots of meetups related to App development, and I’d worked on several projects, both personal and for my employer. (But it was still mostly web-dev at my day job, even though my passion was clearly for mobile.) I gave several talks at a group called Mobile Twin Cities, and the founder of that group had a mobile consultancy, and he recruited me.
Take-away 6: Find user-groups in your area that are relevant to the work you want to do. Attend them and (ideally!) find a way to give a talk. (Or at least address the group for a few minutes. Most groups have time for announcements.) Putting yourself out there, especially in a way that shows off your skills/abilities, can be crucial to landing any job in tech.
I think I was only at that company for 6 months before another merger was announced, and a year later, I found myself no longer writing mobile apps, but doing macOS desktop application development instead. I lined up a contract gig, (fortunately a very flexible one), and gave my notice.
They convinced me to stay a whole month before leaving, but in 2012, I began working freelance/contract, and I’ve been my own small consultancy ever since. I’ve even managed to work on a bunch of games! (Though my passion is definitely still mobile, I’ve done some VR work, and I’m currently very excited to work on some projects in visionOS.)
