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 hookin
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.
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.
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: 12.
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.
Are you referring to this issue? It seems to me that the problem is caused by Firefox making some text disproportionately big compared with other text due to its minimum font size settings, and you can fix the problem by changing Firefox's settings to not interfere with the font size.
This is no indication of that. One of the biggest problems web developers face is people using old browsers that aren't as technically capable. It increase the effort required to implement and maintain features, particularly for large, complex web applications.
Google have a long-standing policy to support the most recent major version of browsers and the previous major version. What prompted the dropping of support for Internet Explorer 9 was the release of Internet Explorer 11 a couple of weeks ago.
They described this policy - which applies to all browsers, not just Internet Explorer - a couple of years ago. When they did so, they explicitly provided links to download the latest versions of major browsers, including Internet Explorer.
This is not a conspiracy to punish Internet Explorer users. This is an effort to reduce unnecessary work for their engineering teams.
Yes, Enable Location Services. No, don't use iCloud. No, I don't want to answer security questions. I told you this when I set up the phone the first time, and every time I've updated. Why do you keep asking me?
Isn't this something that configuration profiles handle? You aren't setting up every iPhone manually are you?
When you write a book you almost always start from scratch
It's incredibly common to update a book. Haven't you ever heard of different editions?
When you write code that is an update to an old software, you re-use a lot of the old code.
Yes, and then you make changes to it. By definition, that's what updating software is. Those changes can introduce new problems, just as rewriting a chapter of a book can introduce grammatical errors.
So, there is no excuse for that.
You are literally demanding perfection. Exactly how many professions are there where people don't make mistakes?
Compare it to writing a book and making a grammatical error. The rules of grammar are nothing new, people have been writing books for centuries, and there are even tools that can automatically check a lot of it for you. How on earth could anybody publish a book with a grammatical error!? THERE IS NO FUCKING EXCUSE FOR IT!
A bug like this is the equivalent of a grammatical error when writing a book. The simple fact of the matter is when you've got humans writing millions of lines of code, some of them are going to make mistakes, and some of those mistakes are going to end up in the final product, even assuming the best intentions from everybody involved. NASA puts more work into writing bug-free code than any other organisation, they make it their highest priority and even they can't write bug-free code. Software development is intrinsically flawed when it comes to bugs because people aren't infallible.
Applications should not be able to do this on their own
They can't. All they can do is provide a configuration profile. This then prompts the user, who has the choice whether to install it or not.
This feature is aimed at the enterprise market, where you don't want to walk your ten thousand employees through how to set up their email because even if 1% of them are idiots, you end up with a hundred people wasting your time.
That's insane. He's asking about frameworks that will continue to be supported in the future, and you're telling him to use one that is guaranteed to have zero support.
There's a time and a place for people writing their own frameworks, and this is 100% the opposite of it.
You know it's not really all that difficult to see the writing on the wall for some technologies.
Flash in particular you could see coming from a mile off. It was a web browser plugin that hated the web. It tried its best to fight against web technologies at every turn. Many aspects of the web - URLs for discrete resources, the DOM for discrete page elements, source-based delivery, cross-platform authoring, open-source authoring, etc. - were actively subverted by Flash. So all the forward progress for the web that improved or relied on these things fell by the wayside for Flash.
Likewise with PHP frameworks. With few exceptions mainly relating to lock-in, everybody who's got any taste and skill abandoned PHP years ago or never took it up in the first place. As a consequence, this leaves the people driving PHP forward very poor stewards. PHP is a zombie at this point - the killing blow has already been struck, it's already dead, it's just going to take a while for this to become so obvious it cannot be ignored. Competent people don't do things like cause security issues because they make releases after ignore failing tests.
You say that you deliberately eschewed open-source, but if you look at where the forward progress for the web has been coming from, it's predominantly open-source projects.
I just don't see how you can have any understanding of this industry and continue to make those kinds of choices.
Slashdot Mirror
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.
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.
My company develops Android, Facebook and Twitter applications. Exactly how do you propose I avoid having Google, Facebook, and Twitter accounts?
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 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.
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.
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.
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.
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.
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.
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.
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.
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 hookin
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 disli
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.
Are you referring to this issue? It seems to me that the problem is caused by Firefox making some text disproportionately big compared with other text due to its minimum font size settings, and you can fix the problem by changing Firefox's settings to not interfere with the font size.
Not really.
This is no indication of that. One of the biggest problems web developers face is people using old browsers that aren't as technically capable. It increase the effort required to implement and maintain features, particularly for large, complex web applications.
Google have a long-standing policy to support the most recent major version of browsers and the previous major version. What prompted the dropping of support for Internet Explorer 9 was the release of Internet Explorer 11 a couple of weeks ago.
They described this policy - which applies to all browsers, not just Internet Explorer - a couple of years ago. When they did so, they explicitly provided links to download the latest versions of major browsers, including Internet Explorer.
This is not a conspiracy to punish Internet Explorer users. This is an effort to reduce unnecessary work for their engineering teams.
Isn't this something that configuration profiles handle? You aren't setting up every iPhone manually are you?
Isn't the E.T. game a collectable these days?
From the article summary:
It's incredibly common to update a book. Haven't you ever heard of different editions?
Yes, and then you make changes to it. By definition, that's what updating software is. Those changes can introduce new problems, just as rewriting a chapter of a book can introduce grammatical errors.
You are literally demanding perfection. Exactly how many professions are there where people don't make mistakes?
Compare it to writing a book and making a grammatical error. The rules of grammar are nothing new, people have been writing books for centuries, and there are even tools that can automatically check a lot of it for you. How on earth could anybody publish a book with a grammatical error!? THERE IS NO FUCKING EXCUSE FOR IT!
A bug like this is the equivalent of a grammatical error when writing a book. The simple fact of the matter is when you've got humans writing millions of lines of code, some of them are going to make mistakes, and some of those mistakes are going to end up in the final product, even assuming the best intentions from everybody involved. NASA puts more work into writing bug-free code than any other organisation, they make it their highest priority and even they can't write bug-free code. Software development is intrinsically flawed when it comes to bugs because people aren't infallible.
They can't. All they can do is provide a configuration profile. This then prompts the user, who has the choice whether to install it or not.
This feature is aimed at the enterprise market, where you don't want to walk your ten thousand employees through how to set up their email because even if 1% of them are idiots, you end up with a hundred people wasting your time.
That's insane. He's asking about frameworks that will continue to be supported in the future, and you're telling him to use one that is guaranteed to have zero support.
There's a time and a place for people writing their own frameworks, and this is 100% the opposite of it.
You know it's not really all that difficult to see the writing on the wall for some technologies.
Flash in particular you could see coming from a mile off. It was a web browser plugin that hated the web. It tried its best to fight against web technologies at every turn. Many aspects of the web - URLs for discrete resources, the DOM for discrete page elements, source-based delivery, cross-platform authoring, open-source authoring, etc. - were actively subverted by Flash. So all the forward progress for the web that improved or relied on these things fell by the wayside for Flash.
Likewise with PHP frameworks. With few exceptions mainly relating to lock-in, everybody who's got any taste and skill abandoned PHP years ago or never took it up in the first place. As a consequence, this leaves the people driving PHP forward very poor stewards. PHP is a zombie at this point - the killing blow has already been struck, it's already dead, it's just going to take a while for this to become so obvious it cannot be ignored. Competent people don't do things like cause security issues because they make releases after ignore failing tests.
You say that you deliberately eschewed open-source, but if you look at where the forward progress for the web has been coming from, it's predominantly open-source projects.
I just don't see how you can have any understanding of this industry and continue to make those kinds of choices.