The sucky app management I was referring to was that every installed app is automatically on a home screen. That's a shitty thing.

For you perhaps, but it's exactly the right thing to do for most users. Average users don't install hundreds of applications. When they install an application, it's better for them to have it immediately available than tucked away somewhere they have to go find it. If they do use a lot of applications, they can easily move it out of the way.

Folders don't help.

Why not? You have your most frequently used applications on your home screen, and the rest are available when you tap on an icon. How is that different to what you are doing with Android?

Removing applications has been this awkward on every Android device I've owned. Samsung Galaxy Tab 2, Sony Xperia Pro, HTC Desire Z, and Google G1. Another phone too somewhere in the middle, but I can't remember off the top of my head which it was. This isn't a problem that is limited to a single manufacturer's customisations, they have all been pretty shitty.

Nope. As soon as I start dragging the icon, it shows the home screen. There's a "Remove" target I can drag it to, but it doesn't work because that's for removing stuff from the home screen.

I'm curious what you mean by "sucky app management". One of the things that really bugs me about Android is that the standard way of removing an app from a device is to go into Settings > App Management > Pick the app > Uninstall, which then pops up a dialog box confirming deletion. On iOS, I just have to tap and hold the app icon, then tap the x, which makes the app disappear instantly. iOS seems to have the clear advantage there.

not have every damn app as an icon on a home screen

Put your apps in a folder. It becomes the functional equivalent of the app drawer on Android, except you can have as many as you want and give them names.

And of course, once you take into account normal use patterns not Slashdotter use patterns, iOS seems to have even more of a lead. When you install apps, they appear on your home screen by default, not hidden away in the app drawer. That's far more sensible for normal users. And you do realise that downloading torrents on your phone is an extremely niche use pattern, right?

There's lots of problems with Facebook, but let's not pretend you're completely helpless about other people's photos of you.

If you're tagged in a photo, you can exercise your privacy controls over it. If you aren't tagged in the photo, a prospective employer isn't going to see it when they look at your profile.

judging from the number of accounts you have with Big Data Aggregators, I'm afraid you might be blind to it.

My company develops Android, Facebook and Twitter applications. Exactly how do you propose I avoid having Google, Facebook, and Twitter accounts?

Every account where you have an authentication from somewhere else serves only to increase your vulnerability to having the account hijacked.

My Google, Facebook, and Twitter accounts are all configured to use two factor authentication. The simplest way of hijacking them is to have a) my password, b) my phone, and c) my fingerprint. A username and password for Feed.ly doesn't make me safer, it's just an inconvenience.

That's $99 per year, to even be able to try coding for iOS.

That's not true. It's free to download Xcode, free to develop applications, and free to run them on the iOS simulator. You don't have to have a paid account to learn how to develop for iOS. The fee is to publish applications in the App Store and on devices.

Plus, you need a recent/current Apple computer running the current MacOS to run the dev tools on.

The multi-platform thing, I'll grant you. As for recent, well you need a Mac from 2007 onwards. The oldest I've personally tried was 2008, and it was a bit slow, but perfectly usable for professional purposes. Try running the Android emulator on a six year old computer - it's incredibly slow on brand new ones.

I don't want to notify my Google+ circles that I just added something to my feeds, and inevitably that's what will happen.

It's not inevitable. When I added a feed in the old Google Reader it didn't tell anybody I was doing it. Just because Google has Google Plus, it doesn't automatically translate that each and every action you take while authenticated must necessarily be shared. Even if you assume that is the case, the whole reason why the Circles feature is designed the way it is is because Google acknowledge that it's not appropriate to share everything with everybody. You're literally taking a feature that is designed to limit sharing and ascribing to it the opposite intention.

They want to tie your Feedly account to some other social network to increase its marketing value to them. The more interconnections they can associate with your account, the more valuable it is to them.

Do you have any evidence for this or is it just your supposition? When I build a website, I prefer to use third-party authentication schemes because it's the right thing to do. I don't give a shit about marketing value, I give a shit about not pushing yet another login system on people when there's no need for it.

Open: Android is "open" in the "open cathedral" sense. It's very difficult to just jump in, make a few alterations, and see the changes running on your device.

Wait, are you an app developer or an OS developer?

I'm not talking about the technical difficulty in writing a patch. I'm talking about the difficulty in applying a patch in practical terms. If I want to, say, modify my Xperia Pro so that a particular application that is useless to me isn't forcibly bundled, it's far more difficult than it should be.

Apple can make you waste vast amount of money developing something only for it to be blocked, and then copied by Apple themselves. That's more than a big deal. It's hard to get projects approved when managers see this happening.

I deal with people who commission apps on a regular basis. Unless the entire concept of an application is forbidden by Apple (e.g. porn), it's never been a deal breaker.

But with Android, you have to contend with thousands of different models, each with their own shitty customisations that break things.

Only if you are a terrible programmer. Like most operating systems Android runs on multiple platforms and offers stable APIs to interact with that hardware.

Which means nothing when vendors customise the implementations of those APIs and break them. It's all very well saying that, say, the API to draw a control on screen is the same across all devices, but if one device draws the control and another doesn't bother, that's kind of a problem.

Can you provide any concrete examples of standard Android API functions that are broken on popular Android devices?

I don't remember the full details, but the most egregious problem we had was that radio buttons simply weren't showing up on one device. At all. On another device, the rendering was completely fucked in some way, something like being a tenth of the size they should be or something. The code was right, and the application worked just fine on most of our test devices. But on some, they simply didn't work right due to vendor customisations.

99% of the time, it's when the client is asking for us to do something user-hostile.

You mean like develop an alternative HTML rendering engine, or set up their own app/book/music/video store, or write a better SMS messaging system, or port their keyboard from Android, or some nefarious scheme like that?

Let's be straight here: I'm describing what Apple's policies mean for us in practice, and I'm reporting what clients actually ask us to do. You are scraping everything you can think of that Apple has ever rejected together. I'm sure there are lots of business plans that have fallen by the wayside in the five years Apple have been running the App Store. But that doesn't mean that they are a significant percentage of the apps people actually want to create.

No client has ever asked us to develop an alternative HTML rendering engine. Why would they? Besides, Apple don't have a problem with an alternative HTML rendering engine.

No client has ever asked us to set up their own app store. There are book stores on the App Store already, there's no rule against having a book/music/video store.

Alternative SMS messaging systems aren't against Apple's rules. I've got one on my phone right now.

No client has ever asked us to replace part of the system like a keyboard. If you have an application that needs a custom keyboard, you can implement one for your application, but you can't replace the keyboard in other people's applications.

When I say that the things clients ask us to do are things that are user-hostile, I'm talking about things like hooking into Safari to show adverts to people while they browse, or spamming everybody in the address book via SMS. These are the things that I see Apple's policies preventing over and over again.

many of the newer features in Android are available via non-OS updates that everyone gets via Play.

No, not everyone gets via Play. You're confusing Play with Android. You don't have to license Play to deploy Android.

And no, having some extras bolted on top of an old operating system is not the same thing as being able to rely on a more recent version. I already provided an example that no Play upgrade would fix.

This really isn't the big issue crap programmers make it out to be.

You are repeatedly insinuating that we are crap developers simply because I am pointing out problems with Android. You might want to think about that.

if a feature isn't available in Gingerbread there probably isn't any point trying to hack around it because devices of that age won't support it anyway.

You're making my point for me!

It takes less than a year for about 95% of iOS users to upgrade to the latest version.

Yes, and now you get complaints that your app is dog slow because the OS runs like a dog on older hardware, but users were not clever enough to block the update and can't downgrade.

No, actually. Not once.

Simple solution, don't buy from shitty vendors.

What are the non-shitty Android vendors? Because I was buying flagship phones with good reviews from mainstream vendors like Sony. And if you were paying attention and knowledgable about Android, you'd know that at least one of my phones was direct from Google.

I dislike the controlling attitude of Apple and I dislike how much power they have in the mobile market.

No, you love it.

And this is the point at which it's not worth talking to you any more. Once you stop arguing against what I am saying, and put words in my mouth that are the opposite of what I believe, there really isn't much discussion to be had.

As a user, what benefit would them having their own authentication system give me? I've already got a Google account. I've already got a Twitter account. I've already got a Facebook account. If they provide those options, that's one less moving part for me to manage. If they create their own authentication system instead, I've got yet another thing to set up.

Even if we assume that prospective users have none of the above, they've still got to set up an account somewhere. Why should they authenticate with Feedly rather than one of the other systems?

I think I'm qualified to comment on this. I've been an iOS developer since 2008. My company makes iOS and Android applications. I used flagship Android phones from 2008-2012 before switching to the iPhone. So I've had a lot of experience with both platforms from both the user and developer sides.

I think Android phones are terrible in comparison to iPhones. The reason why I started out with Android phones was for the reasons you outline - more open, and more flexible. I quickly discovered that wasn't all it was cracked up to be. The reason why I stayed with Android for so long was that a) I was holding out hope that it would be better in the long run and b) I wanted a hardware keyboard.

Open: Android is "open" in the "open cathedral" sense. It's very difficult to just jump in, make a few alterations, and see the changes running on your device. Practically speaking, it's not developed in an open sense in the same way most open source projects are. You could write a book about the implications this has and how it undermines the benefits open source normally provides.

Less hostile to develop for: not a chance. Yes, Apple have the ultimate say-so on what's allowed on the App Store. Yes, that's a big deal. But with Android, you have to contend with thousands of different models, each with their own shitty customisations that break things. We deployed an application last week for Android. It was finished weeks beforehand for iOS. Despite only having to target three recent Android tablets (it was an in-house project), each tablet was broken in different ways. iOS development is a breeze by comparison.

The problem with producing applications for the iPhone is Apple's policies. That's not a development obstacle, that's a policy issue. As we are a digital agency, all this really means for us is that we can say "Apple won't allow that" to clients when they ask for us to do something that Apple won't allow. And you know what? 99% of the time, it's when the client is asking for us to do something user-hostile.

The problem with producing applications for Android is development. The client asks for the feature, there's no intrinsic reason why it can't be done, but in practice you find that what should work and what does work on various devices differs radically.

Then there's the upgrade issue. I've done a lot of web development. Android is the Internet Explorer 6 of the mobile world. Masses of people don't upgrade, and more than a quarter of Android users are still on Gingerbread, released almost three years ago. It takes less than a year for about 95% of iOS users to upgrade to the latest version.

This isn't just a developer problem, it's a user problem as well. When I bought my last Android phone, it was a flagship Sony phone shipped with 2.3 that they had committed to upgrading to 4.0. That's the only reason I gave in and stayed with Android. The promise that I might actually stay up to date for once. Sure enough, they broke that promise. But they dragged it out for a year saying that they would do it. Meanwhile, the version of Android I was stuck on had a bug that rendered my SIP phone line useless.

You lose features too. Remember when OTA upgrades were an advantage over iOS? The year before iOS added that feature, I got an Android upgrade that took that feature away. It was a shitty vendor customisation. I had to use a buggy desktop application that crashed my computer to upgrade Android. When I switched vendors? Same thing, but with a completely different buggy desktop application.

Android's a mess. It was a mess for the fours years I was using it, with every single handset I tried, as I was hoping in vain for it to get better. It never got better, in fact the problems with the platform became more numerous over time. It's "openness" is an illusion and is not going to fix the problems it faces.

I dislike the controlling attitude of Apple and I dislike how much power they have in the mobile market. But Android is so much worse as a platform that I'm happy to let other people fight that battle. I'd rather have a phone I didn't despise.

That's just it, you can't write a client to handle the protocol. Or, more specifically, you can, but that protocol doesn't include the information necessary to write a client. The protocol was designed to be typed by hand and interpreted by a human, not software. When an FTP client shows you a file listing, it is guessing at how to interpret the file listings.

As for firewalls, no, there are problems there as well. Firewalls have to actively watch for FTP connections and treat them specially, and even when they do, they can't get it completely right because the protocol is fundamentally broken.

Don't take my word for it, read what the people who have implemented FTP have to say on the matter: 1 2.

That's always been the case. And it's still the case today that if you want to browse an FTP site, whichever client you are using has to guess at how to interpret the list listings. I was using it as an example of how fundamentally broken the protocol is.

Tracking cookies don't magically appear all by themselves. They are added by the server. They would only be added to a GIMP download if the GIMP servers were configured to do so.

And given that the link went to a normal web page delivered over HTTP that contained an FTP link, if they wanted to serve you a tracking cookie, you would have it already.

Why on earth would you use FTP in this day and age? It's garbage designed for pre-Internet networks. It doesn't even define how file listings work, clients have to use heuristics to guess at how to interpret them. It's got a weird two-connection model that doesn't play nice with firewalls. It should have died a long time ago.