Twitter

Categories

Recently I’ve found myself working with iOS 8 extensions, building Today widgets for Notification Centre using Swift. More specifically, I was attempting to build a widget in Swift for an app built in Objective-C. All was good until I went to run on device, when I received the following error message on the console:

dyld: Library not loaded: @rpath/libswift_stdlib_core.dylib

What I hadn’t noticed was a build setting titled ‘Embedded Content Contains Swift Code’ which by default is set to NO. Flipping this solved the problem, though it’s interesting to note that for projects built in Swift, you can add Swift extensions, leave this setting at NO and run your extensions just fine on device.

A recent feature request stipulated that the user’s location be visible in the various different maps that appear within the app. This is a common enough request and very easy to implement, but what does this mean for battery life of the device? The GPS radio on any iOS device is the most battery-intensive onboard radio and so having GPS running frequently is a bad idea. Time to profile the GPS radio usage!

Given that MKMapView is pretty mature having been around since iOS 3.0, I suspected that it would be intelligent enough to only use the GPS when necessary to determine the user’s location, such as first using wifi, the device’s IP address or some other less battery-intensive operation to determine if the user’s location is actually within the bounds of the displayed map before getting a more accurate reading to display on the map view.

It appears, however, that this is not the case. Rather surprisingly, as soon as showsUserLocation is set to YES until the time it is set to NO or the MKMapView is deallocated, the GPS will run hot, sucking up your juice. Not only will it do this when the user’s location is nowhere near the bounds of the map view, but also when the map view is not even visible to the user, so it turns out that it’s pretty important to manage this property carefully if you don’t want to drain your users’ batteries.

The recent fiasco around The Atlantic’s sponsored article in support of Scientology has highlighted something rather important: disclosing a conflict of interest does not exonerate a news source from poor quality control. A “sponsored content” label basically amounts to disclosure that the source was paid to post an advert in the guise of actual copy, and so this example provides ample evidence of why we as content consumers should not so readily accept the disclosure argument as a means of preserving journalistic integrity.

This all raises another important point. A disturbing trend has emerged in recent years whereby the tech media are posting conflicted content and taking on clearly biased writers while using the disclosure argument as a sort of back door out of accepting responsibility for such shoddy journalism. Let’s be clear– just because conflicts of interest are disclosed, does not mean that a publisher is somehow absolved from this sin.

It is very true that conflict of interest cannot be avoided altogether, but providing a platform for people like MG Siegler and Michael Arrington to make paid regular comment on issues of interest to them seriously compromises the journalistic integrity of TechCrunch. The involvement of both of these authors in the CrunchFund venture capital firm means they largely cannot write without bias on topics relevant to the tech industry. Disclosure does not mitigate this– it simply makes it apparent. They should be free to write whatever they want on their own personal blogs but being paid to write articles for a widely-consumed blog professing to have some degree of journalistic integrity? We should not so readily accept this.

I don’t mean to single out TechCrunch. Many other tech blogs are littered with embedded disclosure statements, post “sponsored content” or even include “disclosed” affiliate links in their posts, such as this example from The Next Web. Again, the disclosure of this fact doesn’t somehow elevate TNN out of the depths of journalistic depravity; it simply makes its lack of journalistic integrity more apparent. Of course, if it were to hide this fact this would be a greater sin still, but this doesn’t detract from the fact that TNN is getting paid to write articles about certain topics, and being paid specifically by those that stand to benefit most from the entailing publicity.

And now with this latest The Atlantic fiasco, it should be even more painfully apparent why we cannot simply accept content peppered with disclosures and assume that all is bona fide. Instead we should seek out news sources that genuinely provide a wide, fair and balanced spectrum of information, ones where disclosures of this sort are completely unnecessary.

Jack Dorsey recently blogged about how they are abandoning the term “user” in favour of “customer” at B2B mobile payments provider Square. This was a shock for me, because in all my years of being a “customer” nothing has irked me more than being considered simply and only that by the businesses behind the products and services I use.

Being a customer implies that you are nothing more than a unit of economic value to the business, a target to be fleeced of cash, a necessary inconvenience that brings little more to the table than dollars and cents. When I use products and services I generally engage with them far more than what the term “customer” implies. Not only am I a customer, for that product I am a reviewer, a quality gate, a contributor, a value creator, a proponent, a promoter, and sometimes even an evangelist. I am not just a customer. Being called a user may be vague, but at least it doesn’t obscure all this and reduce me to a mere financial incentive for the business. Now that really drives me bonkers.

One thing that most consumer software of value does today is to integrate in some way with the major social networking incumbents, Facebook and Twitter. zeebox, naturally, is no different, and we’ve worked fairly closely with Facebook to get our Open Graph implementation right while also ensuring that we make best use of their platform.

There’s been a few bumps along the way. In past, Facebook have gently chided us for pre-filling the message field when posting to people’s walls from the app, which runs afoul of Facebook’s platform policy. Basically, any app that posts to your wall should have an empty field that allows you to express your thoughts about the subject matter you are posting.

But the truth is, there are loads of apps out there that flout this policy.

Draw Something:

Amazon Kindle:

And even some of zeebox’s competitors.. yap.tv:

In all these cases, Facebook’s platform policy is being violated because there is pre-filled content in the field rather than it being blank. In the case of yap.tv, you can’t even edit the text and, worse still, incomplete text is being displayed to the user.

It’s a little frustrating to see that FB’s platform policy isn’t quite enforced with an even hand, though I suppose the benefits of having a good relationship with Facebook outweigh this.

Facebook does many things very well, but most would agree that they are not particularly adept at managing their users’ privacy or security.

A recent example hit me the other day while browsing the Facebook iOS SDK integration docs. Facebook suggest that SDK developers store the Facebook access token that grants a client (e.g. an iPhone app) access to the Facebook platform in the iOS user defaults. This is not secure and could result in someone else masquerading as the user on Facebook or hijacked the user’s identity.

What is a Facebook access token?

A Facebook access token allows a 3rd party app to interact with Facebook on behalf of a particular user. Depending on what permissions the user granted to the app, the holder of the Facebook access token can do anything from posting to a friend’s wall, to accessing all the user’s personal information. It is important, therefore, that this access token is only ever accessible by the app in question.

What are iOS user defaults?

As any iOS developer knows, this is where an app can store a user’s preferences and any other information that might help the app to understand a user better across app sessions. These defaults might store things like a user’s ID, a preferred colour scheme, or the user’s first name, among other things.

User defaults, however, are not secure. Data stored in the defaults is stored in plain text, and while iOS apps cannot access the defaults of another app, anyone who had access to your phone, or a backup of your phone, could easily extract the Facebook access token and use it to masquerade as you. Not a good scenario.

For the past few months I’ve been working at zeebox on a new app for iPad that is genuinely one of the coolest products I’ve come across recently.. and so it has been an absolute pleasure having the opportunity to build it! I’ve been largely working on the social aspects of the app, e.g. Twitter integration, Facebook authentication, and the chat system, which is brilliant as this combines my two favourite spheres of software development: mobile and social.

Basically, zeebox acts as a glorified TV guide with social elements. You can see what your friends are watching ,chat with them about shows, invite them to watch with you and various other things. Despite a huge amount of work going into it, the app is still pretty nascent and it’s clear that it will improve dramatically over time, as long as people within the company continue to dream up more great ideas (this hasn’t been a problem thus far!).

There have been 4 of us working on the iPad app, but naturally there’s also a great team of engineers building the back-end services that tie the whole thing together. iPhone, and Android versions of the app are to follow. Check it out!

After a fair bit of wrangling, it’s finally come together. We’ve partnered with MTV and the Staying Alive Foundation to rebrand iCondom as the MTV iCondom, with a grand portion of proceeds going towards the Staying Alive Foundation, a sexual health charity. MTV will be broadcasting adverts across their worldwide network and ads have been produced in several different languages. See the English-language ad here.

We’re also looking for further partners to help update and maintain our ever-growing database of locations, so please get in touch if this is of interest!

Another raaza app in the wild. This one is US Flu Fighter, which is basically a mashup of various different CDC feeds with Facebook and Twitter in an iOS native app. It’s another one with a Ruby on Rails web services back end, which I’m finding increasingly handy for quickly building such back ends. I used the CorePlot framework to draw the graphs, which was a pleasure to use once i got familiar with it. US Flu Fighter has been submitted to the CDC’s Flu App Challenge so please go ahead and give it a vote.

This is year two for the Addicted to Ibiza Island Guide, a location-based listings app for the Ibiza party crowd. It includes event listings, a club guide, maps, DJ mixes and more.

The back end for this one was built in Java using largely the same components as last year, i.e. Struts 2, Spring, Hibernate, Freemarker and JAXB. If I had to do it again I would probably build it on Ruby on Rails, simply for the increased speed at which the solution could be delivered.

It’ll be available until December this year and then taken out of the store in anticipation of next years guide.