Being more efficient in Xcode - Part 2
This is my second article in the “Being more efficient in Xcode” series. The first part, which you can read here, was focused on keyboard shortcuts.
Besides the keyboard shortcuts, there are other tips and tricks an iOS developer should know, to be able to improve his productivity when using Xcode.
Breakpoints
It’s a pretty good idea to add an ‘All exceptions’ breakpoint. This way, when your app crashes, you’ll get stopped exactly when that happens and you can see the whole backtrace and debug the problem more easily. A good idea is to also add a debugger command action on that breakpoint to print the exception you’re encountering. Open the breakpoint in the Breakpoint navigator, right click your All exception breakpoint, press Edit, press Add action and add this debugger command po $arg1
However, sometimes (especially if you’re using Swift), you might notice that your app always stops in the AppDelegate when launching it. You can manually continue over that, but it’s still annoying. To stop that from happening, you can edit your exceptions breakpoint to only stop for Objective-C exceptions, ignoring other types of exceptions such as C++ ones. Depending on your project, this could be a bad idea, but in most cases it will be fine.
You can also use breakpoints to print variables: just add a po command.
Editor
As we all know and we’ve all been complaining about, there’s no refactoring in Swift. There is, however, a better-than-nothing alternative, which in some cases can be used instead of rename-refactoring. Select a variable (double click on it), go to Editor - Edit all in scope. Enter the new name and it will be renamed everywhere in the current scope.
As the name says, this only edits in the current scope.
Another command that affects only the current scope is ‘Fix all in scope’. This makes the changes suggested by Xcode for all the warnings and errors. This also only affects the current scope. And sometimes, Xcode’s suggestions are not exactly what you had in mind. Nevertheless, this command can still be useful sometimes.
Code structure
Use the Document items list. Open the list (either press on it, or use the shortcut control - 6) and you can see all the classes, extensions, methods, etc in your file. If you start typing, it will begin filtering them in a way similar to quick open, but it will search for entries inside the currently open file.
It’s also a very good idea to use //MARK: in your source. This allows you to organize the methods and other items in your code in a better way. They’re also visible in the Document items list. And also, if for example you have a //MARK: - UITableViewDelegate you can command - click on the UITableViewDelegate and it will take you to the UITableView interface, where you can see all the available methods and their documentation.
Interface builder
And one last tip about interface builder. Did you ever need, for example, to move a button on top of another view, but not make it a subview of that view? By default, when you drop a button over a view, IB will make the button a subview of that view and you will also lose all its positioning constraints. But if you press ⌘ while dropping the button, it will not be a subview, but a sibling of that view.
There are lots of shortcuts in Xcode, and lots of things you can do to increase your speed when using it. The important thing is to take them one at a time.
NSSpain 2016
At the end of 2014, I decided to try and attend at least one iOS conference per year. And after MCE 2015, this year I chose NSSpain.
NSSpain is a conference I’ve been eyeing for a while, I’ve followed it closely in 2014 and 2015, seriously considered to attend, but due to one reason or another, I didn’t do it.
Sad to miss @NSSpain again. Looks like the best combination between iOS and wine. I really hope I can be there in 2016.
— MariusConstantinescu (@marius_const) September 15, 2015
This year I was so determined to be there that I got a ticket as soon as they started selling them.
NSSpain
NSSpain takes place in the city of Logroño, in northern Spain, in the Rioja region (yes, the one that produces the great wine). The conference is organised by Luis and Borja, two great people who I got the pleasure to meet. Although there were some minor hiccups in the organisation now and then, the quality of the conference is amazing for something put together by 2 persons in their own free time.
The event was spread over 3 days: one workshop day (for 40 persons) and 2 conference days (with more than 200 people taking part).
From the workshops day, I must highlight Jorge Ortiz’s architecture workshop. It was informative, high quality and on the subject.
During the 2 actual conference days, I attended all 21 sessions, and I was impressed by most of the talks. There were some that, in my opinion, failed to deliver, but there weren’t that many and they didn’t change my overall impression of the conference.
I’ll shortly write about 3 talks that I think are worth mentioning.
The Road to CocoaPods 1.0
Samuel Giddins has been the lead developer of the CocoaPods project for the last two years or so. CocoaPods is a huge project, indexing over 23000 libraries that are used in more of 1.1 million apps. It has 8500 stars on GitHub, and it has had in total almost 5000 issues. There are around 400 contributors who worked on this project during the 5 years of its existence. Imagine being the lead developer for a project this size. And doing that in your free time.
Samuel told us the road to CocoaPods 1.0, with all its ups and downs. And towards the end of the talk, Samuel announced that he’s stepping down as lead developer, letting others take that role. At the end of his talk, the organisers showed a video message for Samuel from Eloy Durán, the previous lead developer of CocoaPods and Samuel’s mentor. It was an emotional moment, and this was definitely the talk that got the most applauses. And they were not “what a great talk” applauses, they were well deserved “thanks for everything” applauses.
This talk reminded us that, although CocoaPods makes the lives of hundreds of thousands of developers easier, the biggest thing it did for the iOS development industry is that it shaped the community into what it is today. And that is much more important.
The Design of Everyday Language Apps
Natasha Nazari gave a talk about designing a language learning app (slides here). The talk was very informative and it drew attention towards some things that developers don’t usually give much thought to: making your app usable by people everywhere.
A short story she told stuck with me. She was learning Chinese through a language learning app. And although she mastered 2000 Chinese characters, when she got to Taipei she couldn’t recognise most of them, because the handwriting used in Taipei different than the font in the language learning app she was using. It’s minor things like varying the font in the app which make a big difference in this case.
I really enjoyed the talk. Most topics discussed at this kind of conferences are architecture, testing, new, better approaches to doing the same old things. We don’t talk enough about localisation, about thinking of your users, about all the different scenarios your app can be used in, and about making your app useful for more people. We need more of this.
Burnout
The organisers also prepared a round of lightning talks. And I was really impressed by Marin Todorov’s. Marin is a successful iOS developer, instructor and book author, probably one of the most appreciated in our community. He gave a talk about burnout. He showed that burnout can happen to everyone, and we need to be better at preventing it and at helping others who are dealing with it. Burnout is more common than we want to admit in our industry, and seeing well-known developers draw attention to it and talk about it will hopefully make us more aware of burnout and help us prevent it for ourselves and for our friends and colleagues.
Please, read Marin’s talk turned into a blogpost and share it with your colleagues.
Activities
Besides the workshops and the talks, there were other things that the organisers prepared for us. Lunch was offered for participants, in the same venue as the conference, so we could socialise and meet other people every day at lunch. And the food was very good. Also, big thumbs up for serving wine at lunch 🍷.
In the first evening, after the workshops ended, we had a guided tour of the city. Very informative, and a good way to find out more tips about the local tapas bars. This was also our introduction to Calle del Laurel, a street famous for its tapas bars.
And the last day, after lunch, Marin Todorov organised a presentation karaoke. Participants volunteered to be on stage and give a presentation based on some slides that they’ve never seen before and that were so unrelated to each other, unexpected and hilarious that we, in the audience, just couldn’t stop laughing. The best talk was considered to be Yvette’s, who won a ticket to next year’s NSSpain. A ticket that she’s willing to donate to someone from an underrepresented category who’s starting in iOS.
Hey @nsspain @lascorbe @borjareinares. Can we make this happen? P.S. Doesn’t mean I won’t be there #nsspain16 pic.twitter.com/Ypjpiypr4P
— Yvette (@ynzc) September 16, 2016
San Mateo
Another great thing about NSSpain is that the day after NSSpain ends, the 1-week long San Mateo wine festival begins. This is the biggest festivity of the year in Logroño. People roam the streets, dance, sing, there are marching bands, the tapas bars are full, everybody drinks wine and eats traditional tapas. It’s a crazy feast where the whole city centre turns into a big ambulant party. Many of the NSSpain attendees and speakers also stay for the first weekend of the festival.
Aftermath
What I really enjoy about conferences is the atmosphere. You get to meet so many people that are in the same line of work as you are, and the amount of inspiration you can get is incredible. You can gain so much just by talking to people.
But besides that, there’s also another positive side effect: when you’re back, you just want to do things, try all the stuff you learned about, play with new frameworks and SDKs, you feel full of energy, very motivated and very productive.
Parts of this blogpost will also be used for an article on the Nodes blog
Being more efficient in Xcode - Part 1
One way to increase your productivity as a developer is to know very well your IDE. Xcode is the IDE I’ve always used for developing iOS projects. While it still has some problems, and is lacking basic features such as Swift refactoring, it also has lots of cool features. Using Xcode faster and better is a great way to speed up a bit your development process, and keyboard shortcuts are the best way to start doing that.
For this article, I’ll be using the classic notations: ⌘ - command, ^ - control, ⌥ - alt (option), ⇧ - shift, ↑ - up arrow, ↓ - down arrow, → - right arrow, ← - left arrow. For the sake of clarity, I will be writing the letters in the keyboard shortcuts in capitals. This doesn’t mean that they have to be capital letters, lowercase letters are the ones you need in that keyboard shortcut command.
In my opinion, it’s very important to read this article just to inform yourself on what keyboard shortcuts you could use, and not try to learn them all at once. Trying to remember too many shortcuts at once could probably end up confusing you and decreasing your productivity and speed. Here are the shortcuts I use most often in Xcode.
Basic editor shortcuts
Xcode’s source code editor has all the usual keyboard shortcuts you would expect: ⌘N, ⌘O, ⌘S, ⌘C, ⌘V, ⌘X, ⌘Z, etc. All those are so common to almost every application and they’re spread system-wide, that I’m not going to waste time talking about them. (Small side note, I never use ⌘N in Xcode, because I prefer to right click the group where I want the new file to be placed and select “New file” there. This way, the new file will be created where I want it to, and I don’t have to move it myself afterwards in the group where it belongs). There’s also ⌘F for “Find in current file”, and ⌘⇧F for “Find in Project”. I use these pretty often. For indentation, there’s ⌘[ and ⌘] to indent left or right. Those are all very common shortcuts and not necessarily particular to Xcode. The ones that follow here are the Xcode specific ones I use most often.
Navigation shortcuts
You know how you can go back and forward in Xcode, to show the file you had opened before or the one you came back from? You can do that using the arrow buttons in Xcode, in the toolbar of the editing area.
You can also swipe with two fingers left or right in the editing area (unless you have a storyboard open and swiping left or right actually pans it). Swiping it also gives it a transition animation, which takes around one second. Not very efficient, but pretty cool. However, you can press ⌘^← and ⌘^→ to get the same result. And this comes without the animation (so, faster) and without moving your hands from the keyboard. I learnt this shortcut from Tobias Due Munk at an NSCoderNight some years ago.
Back in the days when we were doing Objective-C, there was also ⌘^↑ and ⌘^↓, to switch between the .h and the .m files of the same class. I’ve been using that a lot and I found it very convenient, but when I switched to Swift one and a half years ago I didn’t need it anymore.
Probably the shortcut I use most is quick open: ⌘⇧O. This pops up a dialogue similar to Spotlight in macOS and searches for a file you want as you type its name. I find this a super convenient and fast way to open the files I need. This feature is a bit broken in the latest Xcode release (it seems that it still focuses on the file that matches your search string most closely, but the list of results is scrolled to a wrong position), but I hope it will be fixed soon. Even with this minor glitch, I still use it every time. I learned this shortcut from Kasper Welner when I started at Nodes.
Another one I learnt from Kasper is ⌘L in a source file, which opens a dialogue similar to the quick open one, in which you type a line number, press enter and you’re taken to that line in the file you currently have open. Very handy when you know exactly which line number you want to go to, but that’s rarely the case.
Using the Assistant Editor
Xcode has this thing called the Assistant Editor, which splits the editing area vertically into two and shows a file on the right side. This is one of the most known features, even for beginners, because you use this to drag outlets and actions from Interface Builder. The special key that triggers the assistant editor is ⌥. ⌥ - click on a file and it will open in the assistant editor. Even if you don’t have the assistant editor open (the 2 column editing area), it will switch to that and open the file you right-clicked on the right side.
As in any IDE, you can ⌘ - click on a class or method to view its declaration (or definition). Well, in Xcode you can ⌘⌥ - click on a class or method to view its declaration in the assistant editor.
You can also combine the assistant editor with the quick open. ⌘⇧O for quick open, type the name of your class, then ⌥- enter to open it in the assistant editor.
To close the assistant editor and use a single - column editor view, press ⌘ - enter.
The assistant editor is great and I use it a lot. However, on a small screen, the assistant editor is annoyingly small, but on a big one, it can really make a difference.
Other editor shortcuts
Using the quick open to open files means that you won’t always have the file you’re currently editing highlighted in the project navigation area on the left. If you want to see it there, you can always press ⌘⇧J to open any groups, subgroups necessary and highlight the file you’re currently editing.
You can ⌘/ on one or many lines to comment them. For me, sometimes, this keyboard shortcut fails, and I have to go to Editor - Structure - Comment selection. Then the keyboard shortcut works again. I don’t know what causes this, but I hope it gets fixed soon.
Product shortcuts
Now that we’re done with the navigation keyboard shortcuts, let’s go quickly through the Product ones. ⌘B builds the project. ⌘R runs the project. ⌘. stops it and ⌘U runs the tests (I thought of Unit tests to remembering this shortcut. ⌘T will just open a new tab)
Finally
That’s it from me regarding keyboard shortcuts as ways to improve your Xcode productivity. Again, I want to emphasise that trying to remember all the shortcuts at once after reading this article will probably accomplish nothing. So choose one or two shortcuts that you feel you need the most, remember them, use them as much as possible for 2 weeks or so, until they’ve become a reflex, and then come back and learn some more shortcuts.
Those are definitely not the only shortcuts. They’re the ones I use most. For a complete list of shortcuts, see Apple’s documentation
My first iOS app
This week I read Becky Hansmeyer’s article “We all have to start somewhere”, and it surprised me. Becky says she only knows one person in real life that develops iOS apps.
My first contact with iOS development was during my BSc. studies. We were a bunch of students and a passionate teaching assistant, and we were learning iOS development on our own, outside of the university curriculum, following Paul Hegarty’s Stanford CS193P course on iTunes U.
Hearing that there are iOS developers who only know one other iOS developer in real life made me realise that I was fortunate to not be alone in my journey. This makes me put even more value on our great iOS community, on all the knowledge that is shared out there through blog posts, video talks, open source apps, libraries and frameworks, and also on all the conferences and meetups that enable developers to meet each other.
Regarding Becky’s challenge, it’s hard to say what my very first iOS app was. The very first iOS app I wrote and compiled was probably a calculator, one of the first homeworks on Paul Hegarty course.
The first project I did on my own (without it being an assignment) was a Cocos2D game, inspired by the 2d flash helicopter game. The user could control a bird and had to avoid flying too high, too low or crashing into baloons.
All the graphic resources used in the game were found online. I’m not sure if they were in the public domain or not, but I never wanted to publish the game, I just wanted to learn. That was also the moment when I realised it’s very hard to create iOS games without also having a graphics designer in your team.
And if it comes to the first app I worked on that made it to the App Store, then it must be GeoReporter, my Google Summer of Code 2013 project.
Yes, we all start somewhere. Not everybody starts in the same place. But fortunately, we have lots of examples in the community showing that it doesn’t really matter where you start as long as you love what you’re doing and you’re doing your best
How I got my first job as an iOS developer
I read @orta’s excellent article about how to get your first job as an iOS developer, and that made me think a bit about the process through which I got my first iOS job.
In 2013, I took part in the Google Summer of Code as a member of the City of Bloomington organization. My task was to work on their open source iOS app for non-emergency issue reporting. If I remember correctly, that was the only proposal I sent, because I really wanted to work as an iOS developer and that position in the City of Bloomington organization was the only one that interested me.
Before that, I had some very basic iOS experience: I watched some of Paul Hegarty’s course at Stanford on iTunes U and my bachelor thesis project was an iPad app. Besides that, I also had a pretty solid background in Computer Science. But the GSoC experience was when I actually dived head first into iOS programming. At the end of the summer, I had 3 months of iOS experience, some pretty good open source contribution, a nice thing to add to my iOS developer portfolio and 2 recommendations from my GSoC mentors.
After GSoC, I started looking for a part time job as an iOS developer in Copenhagen. Now, good iOS developers are hard to find, but in the autumn of 2013, not many companies were interested in a junior iOS developer who could only work part time because he wanted to finish his MSc studies. Looking over the article, I realize now that I went through almost all the phases described there, so I can take them one at a time.
Readiness
I knew I didn’t have much experience, I knew I still had a lot to learn, but I had worked on 2 apps before, I could find may way around Xcode, I had a good background and I could learn fast. I also wasn’t afraid to admit that I don’t know something and I showed a genuine interest and curiosity about the things I didn’t know. With that in mind, I tried not to create false expectations.
Lookout
There are some job sites in Denmark, but there weren’t many iOS developer positions advertised there. Also, they were all full time.
I was told that in Denmark, the practice of sending unsolicited applications is quite common, so I gave it a try. I started looking for companies that were doing iOS development and sent unsolicited applications to the ones that interested me the most. The problem with unsolicited applications is that they take a lot of time to be replied to. I once got a reply 2 months after I sent the application. This whole process takes a lot of time. I didn’t want to have too many irons in the fire, so I started by sending one application to a company, and then waiting for it to reply. I got a reply after one week and I was invited for a coffee (which I mistakenly confused for an interview). The meeting was scheduled for the next week and, since they didn’t have an available position at the moment, I was basically at the same place where I started, but 2 weeks later. After that, I started sending unsolicited applications to 2 companies at the same time, so I could hopefully speed up the process.
Intro email
This is probably where I didn’t do enough, and it could well be the reason most of my unsolicited applications didn’t get any replies. My emails were quite short, I didn’t want to bother the reader (I still consider this a plus), but they were mostly about me. Somewhere along the lines of “I am a student, I did an iOS app in the GSoC programme, I want to work part time as an iOS developer”. Not much or nothing about why I sent this email to that company. And that’s a pitty, because I actually didn’t send an email to all of them at once, but I had a list of companies, with pluses and minuses for each and I had them sorted according to my preference for them. If I had done this the right way, probably I would’ve got more replies.
Coffee
The idea of getting coffee ☕️ with potential employers was new to me. So new that I actually considered an invitation for coffee to be an interview, which made me quite disappointed when I realised that there were no positions available. It all makes sense now, but back then it didn’t. I got invited for coffee with 2 different companies, and I actually enjoyed meeting people that do what I also wanted to do. I had some great meetings and I had hopes for a potential job interview with one of the companies, either in January or in the spring of 2014.
A “coffee” was actually how I found my first iOS dev job. But since this is Denmark, that “coffee” was actually a beer 🍺. I was participating in the weekly NSCoderNight meetings, some casual get-togethers for iOS developers. That’s where I met Kasper and Johnny, who are now my colleagues. They were looking for a senior iOS developer to join them at Nodes. I had actually seen the job announcement for that position, but decided to ignore it since they needed a full time senior developer, while I was a junior who could only work part time. We talked a bit, each of us about the projects we were working on at the moment, I remember I showed a small demo and also a bit of code, and from there, things moved very quickly. Next day, Kasper contacted me saying that they talked to their CTO and if I was interested, they were open to a part time position as well. I was interested, I had an interview the following day and I started on Monday of the following week.
Interview
The interview went on really well and the process was faster than I expected it to be (but that was probably a one time thing). First they told me about the company, then I told them about myself, about my background, studies, experience and current and future plans. I don’t actually remember being asked anything technical, but I suppose that’s because we talked a lot about code at NSCoderNight.
A couple of hours after the interview ended I had been offered the job. I was probably lucky, because the company really needed to hire developers, but I like to see it as the universe’s way to make up for all the months of sending unsolicited applications with no reply 🙃.
Conclusion
It was a happy ending for me, because I still work there (full time now) and I really enjoy what I’m doing. But this thing took a lot of time: I started my job on March 10, 2014. Between September and March, I sent a lot of unsolicited applications, I’ve been to some coffee meetings, I’ve been to a couple of interviews which didn’t really work out, I went to a few meetups and I met a good number of the iOS developers in Copenhagen. And most importantly, I kept working on my own small iOS projects in that period and I kept learning.
UIViewContentModes
This is going to be a very simple and visual post, showing the differences in what an image looks like using different UIViewContentModes. It’s something I really needed in my early days as an iOS developer. So a couple of years later, I decided to make this visual guide.
We’ll use this image here of the Peleș castle in Romania:
And we will show it in a square 200 x 200 UIImageView, going through all the possible UIViewContentModes. The 1x asset used in this project was sized to 224 x 148, with the @2x and @3x being scaled proportionally. For a better understanding, the background color of the UIImageView was set to black and clipsToBounds was set to false. Here are the results:
Some observations:
Aspect fit,Aspect fill,Center,Top,Bottom,Left,Right,Top left,Top right,Bottom leftandBottom rightare non-distorting content modes, they keep the original aspect ratio.Aspect fitwill scale the image while keeping the aspect ratio in order to fit the whole image in theUIImageView. So its biggest side will fit perfectly in the view, and its smallest side will be scaled proportionally.Aspect fillwill scale the image while keeping the aspect ratio in order to fill the wholeUIImageView. So its smallest side will fit perfectly in the view, and its biggest side will be scaled proportionally. This one will be bigger than the view, so depending on theclipsToBoundsvalue, it will either go out of theUIImageView, or show only the portion that fits in it.Scale to fillwill scale both sides of the image to fill the entire view. This will obviously change the aspect ratio and stretch the image.- Even though
Redrawhas the same effect here asScale to fill, behind the scenes they are very different.Redrawforces a redraw of the view (callsdrawRect:in your view) in response to geometry changes (for example, a change of the frame’s value). It’s not generally used, and it doesn’t make sense to use it on standard system views. In this case, the result is the same because we usedRedrawon a standard view, with the default implementation ofdrawRect:(which appears to be using theScale to fillmode).
Making an app for tvOS - part 1
As curious iOS developers, having had the Apple TV for a week, @RuxandraNistor and I decided that it’s time to try and make an Apple TV app. We didn’t have an idea for an app, but we knew we wanted to make one.
Being two iOS developers with limited time for side projects, a lack of experience when it comes to digital design and a strong desire to not make any APIs or backend development, it was quite hard for us to come up with a good idea for an app.
As we had no content, we thought that we could either build a game, or find an external API to give us content. The one thing we always kept coming back to was that it’s very hard and annoying to input text in an Apple TV app. So whatever app we were building, if we showed content to the user, that content had to be browsable, and not searchable. So I could say goodbye to my idea of making a beer journal (like Vivino, but for beers), an iOS project I started and never finished.
As I like tennis, I’d like an app that gives me real time scores for tennis games, ATP and WTA rankings, tournament draws and results and all other kind of tennis news. But all that content was not easy to find in a way that made it easy for us to show it on the Apple TV.
Then we thought that the idea was to complex: we just wanted to make a simple app to see what’s up with tvOS. So we thought of making 9GAG for Apple TV. We were very pleased with the idea, until we realised that there’s no official API for 9GAG, nor an RSS feed for it. So we looked into other similar websites (BoredPanda, BuzzFeed, etc), with no success: none of them had a good API or RSS feed.
So in the end, we chose to make a simple game. Three hours later, we had our first prototype running. Now we need to add more complexity, make it pretty and make it catchy. More about that in a future post.