I asked the Twitterverse the following question:
iOS Developers: Coffee or Green Tea?
I was only half-expecting useful responses. But since I got 23 answers, I figured I might as well tabulate them.
René Lindhorst attended the MobileTech Conference in Munich in April. He snapped this picture of a slide stating “we use our phones to manage every aspect of our lifes”. You can tell that this conference was in Germany due to the misspelling of “lives”. 🙂
I still love that they chose our new 2.0 iWoman icon top left, as indeed my wife (and many other humans of the female persuasion) use iWoman to manage a very important part of their lives. And thanks for putting it in good company: I see Pages, Evernote, Carcassonne and Angry Birds there, all apps that I also have installed, too.
When you are looking for ways to increase exposure to your site or apps you have a plethora of options of holes that you can pour money in to. I found that milage varies enormously.
Google AdWords wanted me to have another look at their offering and gave me a credit for 100 Euros to spend on their ad network. At the same time I put exactly the same banner ad on 3 sites that I found when browsing the BuySellAds list of publishers. Also I’ve had several customers for putting ads on the Cocoanetics site, one app, and three ads for two components.
Let’s have a look at the numbers to see if we cannot figure out some feel for the varying effectiveness.
When I saw this creative job advert I figured, why not pull together the most interesting iOS jobs into an article. I keep telling you that more companies are hiring than there are iOS software engineers looking to be hired. Now here’s the proof.
I was contemplating several forms of establishing a platform that you could refer to. Should I put it on a dedicated Jobs page on Cocoapedia? Make a jobs page on this here blog? Write about it?
All of the above. So far 7 companies have sent me links to their job specifications. Since this is a large enough first sample to call that “many companies” here’s a quick rundown and commentary on the jobs.
Ever since I got my first earbuds with an Apple device (must have been an original iPhone) I’ve been wondering something, maybe you as well: what is the purpose of this extra clip on the wire. There’s this movable thingy between where the cable parts and the earpiece.
In fact if you google that, then there’s only one other person that asks the same question:
On my iPhone headset (the one that came with the device, as well as the in-ear buds) there’s a little piece of plastic that slides on the cable to one earbud, and can clip onto the other cable.
- It’s not large enough to accommodate the headset cable below the split, so it can’t be used to somehow hold the cable in place when it’s curled up.
- It’s not tight enough to stay in place if I slide it nearer the earbud, so it can’t be used to essentially move the point where the cable splits closer to the earbuds.
- It’s not tight enough to really hold on to the other earbud cable. It takes nearly no effort at all to pull the cables apart.
What in the world is it good for?!?
After some research we found what it is mean to be used for, as well as several other tricks with Apple cables that you might not have known.
On my second day of the first BarCamp I awoke early and felt inspired to prepare notes for a talk on what I found so far to be the most interesting way on how to make money on this ecosystem that Apple has created for us.
When I gave this talk I ran out of time and felt a bit “incomplete” as there would have been several interesting points towards the ends of my note. But the room was full and judging from the fact that people asked several interested questions (and nobody left) people seemed to be ok with that.
Being a reader of this here blog you now reap the benefit that I translated my presentation structure filled in with some commentary for coherence. And this also contains the entire notes, the “Director’s Cut” if you will.
Conferences are an interesting diversion from the daily work as an iOS developer. BarCamps are the same, but they are not classical conferences in the sense that an organizer takes care of everything and you can simply consume. Rather at a bar camp you bring your own content. That’s why they are also referred to as un-conferences.
I visited my first such event in Graz, let me give you some of my impressions. Welcome to the BarCamp Graz 2011.
Apple consciously separates mutable and immutable variants of classes in Objective-C. If you have an NSString you cannot modify it, only by creating a new one with additions to an old one. If you want to
mutilate mutate the string itself you have to use it’s subclass NSMutableString. Internally those are the same CoreFoundation type, yet the design choice was to have an immutable class and add mutability methods in a subclass.
There are two items that are not immediately obvious if you start out learning to program Objective-C, that I’d like to chronicle. One of these stumped me just a few days ago.
In this article I want to summarize a couple of “barefoot techniques” for tuning your views. Sometimes you are painstakingly putting together a UI with multiple views and you cannot tell any more where one ends and another begins.
The debugger is not really working well on this because most of the interesting information about views is hidden behind properties and you cannot usefully inspect their current contents because properties are really methods the value of which is only set when you actually call them.
But I want to share some easy techniques that I started using so that I can get this visual puzzle untangled.
Somebody people told me that some function in my NSAttributedStrings+HTML would take forever but whenever I tested it, I could not see anything wrong. Then Stuart Carnie was able to send a snippet of code that, when pasted into appDidFinishLaunching, would exhibit the same problem, duplicatable.
I was stumped at first. How could I have missed it? But at second glance Stuart did not reference any of my classes, but was only using standard SDK calls. Yet, those are almost identical to what I had wrapped into DTCoreTextFontDescriptor, my Objective-C wrapper.
Then it dawned on me: this might be a lazy loading problem. Or maybe even a bug in CoreText.framework.