On Google Play removing Argentinean apps

Update

As expected (and hoped) Google ended up not removing apps developed by Argentinean companies or individuals. This is the right move, but still, the way the “bad news” were originally communicated leave a lot to be desired.

I woke up this morning to the news that Google Play would no longer accept apps from developers in Argentina “Due to ongoing challenges making payments to Argentine developer” (Google’s official statement is here. I saw it first reported on Celularis in Spanish, then on The Verge in English, and there was a thread in Slashdot as well if you want to read some opinions on politics).

While doing international businesses in Argentina might be more challenging than in other countries, it’s certainly possible. Apple doesn’t seem to have any issue wiring money and following all the local laws, so why is Google thriving?

One thing that’s clear, is that Google wants to start using Google Wallet for payments instead of AdSense accounts. However, so far, Google hasn’t changed anything in AdSense where it’s still possible to create and account while being based in Argentina (which means they have means to pay in Argentina).

So is this really about “ongoing challenges” or about Google’s recent “focus”?

I think it’s a combination of two things:

1. Google wants to automate as much as possible, and pushing wallet might be simpler for them (for reasons I don’t understand).
2. Google doesn’t care enough about its developers.

The second is the one I can’t swallow. Developers are what make a platform popular. As a company, you should try to help them, not piss them off, and try to keep their businesses helthy.

A matter of manners

Is this really an announcement to be be made via email on a Friday at 8PM as it was done?
Couldn’t it happen that some of the companies or individuals whose apps are being pulled shortly have families or employees that rely on the income the app business generates?

Blaming others

The subtext of Google’s communication is that Argentina’s regulations are to be blamed. However, they conduct a business here with AdSense, and have offices here as well.

I really hope Google reverts this soon, before having to pull any apps from Google Play. It would be a demonstration that they care about our development community. I’m not holding my breath, though. In the meantime, maybe we should publish apps from Google Island instead, where Google Wallet is the only mean for payments and taxes are probably deprecated.

Problems with Core Data Migration Manager and journal_mode WAL

Recently for a major update of an app I’m working on, I had to use a Core Data Migration Manager for the first time.

I run into a weird problem with some pragma statements set in the underlying SQLite database, so I’d like to offer a workaround in case someone else runs into this issue in the future.

An iOS Developer WWDC 2013 Speculation

As WWDC 2013 closes in, speculation season begins for Apple enthusiasts. In addition to that 2013 has been a very quiet year for Apple so far (in terms of events and announcements) and a lot has been written about a UI refresh on iOS and the usual expected hardware updates.

As an iOS developer, I’ve been following the development of iOS for years and integrating the new OS features as they were rolled out. I think we can make some educated guesses based on the state of some APIs, and how they have been rolling out in the past few years.

For starters, I think Apples does this intentionally: a new API is rolled out, Apple recommends the devs to start using it, and at some point there are so many apps using it, that adding a new OS level feature related (or requiring) that API is easy and makes all the apps support it immediately.

Here are some technologies / APIs that I’ve identified in the last few releases of iOS and OS X that I believe can shed some light on the future of iOS.

Autolayout

Apple has been very conservative when changing display sizes. They impelemented pixel doubling when moving to retina displays, making apps run at native resolution with no effort from the developers.

Later, with the iPhone 5, they only changed the height of the screen which made supporting the new screen straighforward¹.

iOS 6 brought us Autolayout to manage layout constraints, instead of the old method of springs and strouts. While great, I think autolayout is overkill just to support taller screens, where springs and strouts suffice.

Does this open the door for other screen resolutions, and aspect ratios? Let’s only hope we don’t end up with the crazy world Android is.

SceneKit

I haven’t used SceneKit as I’m mostly an iOS developer (at least so far). SceneKit provides an Objective-C API for 3D, neatly wrapping OpenGL calls.

I’ve only heard good comments about the API. It seems to be solid, and Delicius Library 3 recently launched doing its UI with it.

Are 3D interfaces in our future? I think it’s possible.
Could this power new games on an Apple TV that allows apps? I can’t tell.

The only thing I’m sure is that SceneKit in Mountain Lion seems might only the tip of the iceberg. Remember that Core Animation was introduced in Mac OS X 10.5, way before it became the engine behind UIKit (at least for the public).

XPC

According to the XPC docs:

XPC provides a lightweight mechanism for basic interprocess communication integrated with Grand Central Dispatch (GCD) and launchd. The XPC Services API allows you to create lightweight helper tools, called XPC services, that perform work on behalf of your application.

iOS is definitely lacking means of inter-app communication, and XPC seems to fit as an API to provide it.

Apple appears to be using it under the hood when it uses Remote View Controllers, so it’s not far-fetched to think it will take a more relevant place this time around.

Maybe it’s not XPC the technology we’ll see, but a higher level version of it like Remote View Controllers, but I do expect XPC to be a part of some -very needed- interapp communication in iOS 7.

UIAppearance

UIAppearance made its debut in iOS 5. It provides a proxy class to change the appearance of your native controls such as UIButton, UINavigationBar, etc.

I think UIAppearance may have played (and at the time of this writing is playing) two very important roles:

1. It provided a good incentive for developers to stick with standard controls instead of trying to roll their own. To me, this means that if iOS 7 has an updated UI that appeals to some developers that decided to use UIAppearance to change the look of some OS controls, it will be pretty easy for them to revert and start using the native iOS 7 look.

2. It might have been a good way for Apple designers to play and try different designs and reskin the OS default controls during the development stages of iOS 7.

Closing comments

While trying to figure out what Apple will come out with may seem akin to Kreminology, in the past Apple openly tested new frameworks with early versions of the OS only to later start enforcing their use, or beef up the provided funcionality to entice more developers.

We are only a few weeks away from WWDC, and I can’t wait to see what’s in store. Here’s hoping for great incremental updates as well as some unexpected surprises.

CocoaPods for internal libraries

CocoaPods is a great way to manage dependencies (mostly open source code) in your iOS or OS X project. It implements a Gemfile like configuration file (called a Podfile) where you declare your dependencies and provides all the means to keep those libraries up to date as your project grows.

I want to cover a less common use of CocoaPods: creating your own Pods repository for internal use.

How could Apple extend AirPlay

This is a highly speculative article. I’d like to be able to say it’s based on educate guesses, but sadly I think it’s not. In any case, I consider it a good excersice and hope you can join me imagining a future we might not see.

AirPlay now

AirPlay allows for easy streaming of Audio and Video from iOS devices, and with newer devices even to be used as a secondary screen in some apps. The effect is no short of impressing. You tap a few buttons, and whatever is on your device’s screen magically starts showing up in the scren, with the correct aspect ratio (I’m actually waiting for an NBA game¹ to start as I write this, streamed from my iPad next to me)².

There is, however, something that puzzles me when I use AirPlay: the processor on the Apple TV is mainly idle aside for the (probably GPU bound) task of decoding a video stream.

AirPlay 2.0

What I envision is an extension of AirPlay that allows apps to offload part of their processing to the Apple TV. I think it’s feasible, and even more, some important pieces of the puzzle (APIs) are partially there.

With an API similar to XPC, a future iOS API could allow devices to start a process remotely on the Apple TV and provide means for communicating between the devices. Want a Draw Something-like app? The controller that manages the turns might run on the Apple TV, while each device connected to it acts as the drawing board for each of the teams.

There are already apps that do something similar to this, but they require one of the devices to be the master and run the game for the rest. With the AirPlay approach, the Apple TV would take the role of the master, leaving more processing power for the devices.

Why not Apple TV Apps instead?

I think Apple TV Apps are comming. It’s just a matter of when, not if.
However, I also think for a casual user, it might prove too complex to have to download a companion Apple TV app in order to play a group game. For common users it might be easier to start a session from the device they already have ³ rather than requiring them to download an additional app on the Apple TV (which may be not their own, but a friend’s).

Conclusion

I fully expect Apple to make a bigger move into the living room, and I expect that move to come from cleverly written software rather than amazing hardware.

This AirPlay extension has been in my mind for a long time, and thought it was a good time to speculate about it publicly.