... is that if apps are denied permission, they may refuse to work (even though the permission requested might not actually needed for the app's official purpose).
It's unlikely Apple would approve an application that did that.
So, what we would need is a change in how permission refusal is communicated (or not communicated) to the app. The OS should always tell the app "yes you got permission", but then just fake the action (return plausible but fake location data, plausible but fake adresses, etc.). Or fail with a code not linked to permission (pretend that there is no cellular network available if user refused permission to use it)
That sounds like a recipe for an incredibly confusing user experience.
The way iOS works at the moment is that if an application tries to access something like your contacts, a system prompt pops up asking the user whether to allow it or not. If they don't allow it, the application is told this and has to handle it as well as it can. If it fails to do this well, it won't be approved by Apple. Once the user has allowed an app to access something twice or refused it twice, this preference is remembered and the user isn't prompted again.
When you pay for Spotify etc., you aren't paying a musician for their work. You're paying to copy bits on their behalf. Anybody can copy bits without permission, which is why copyright infringement is so widespread.
Paying a musician for their work involves going to see them live, or alternative business models, such as ones based on the Street Performer Protocol. In those cases, you're actually paying a musician to create music.
Could you actually read my comment all the way through instead of stopping at the first few words and assuming I don't know what a web app is? I've been writing web apps for about 15 years. You don't have to explain to me how they work.
the operator of the Web app would've had to copy the AGPL'd software onto their server. They can't make that copy without a license.
As I stated in the comment you replied to, this is something that is explicitly excluded from copyright protection in the USA, so why do they need a license?
My question is not "hur dur, what's a web app?", it's "copyright in the USA doesn't provide them with enough power to enforce this as far as I can see, so what gives?"
Just because they make the data generally available doesn't mean you're allowed to have a copy of it.
Copyright doesn't cover having a copy. That's property law, not copyright law. For example: if you steal a book from a shop, at no point has the copyright holder given you permission to have that copy, yet you haven't committed copyright infringement.
Copyright covers making copies. The copies you make when using it in a web application - installing on the server, copying into RAM, etc. - are explicitly excluded from copyright protection by USA law.
treats web deployment as a trigger to license compliance
How does this work in the USA? If you obtain it from them directly, they are giving you a copy, you aren't copying it yourself - so that's not copyright infringement. Copying software as an essential step in using it does not count as copyright infringement in the USA - so installing it on your server doesn't count as copyright infringement. Responding to incoming web queries doesn't copy any of their work - so that's not copyright infringement. So if you aren't doing anything that is protected by copyright, why do you need a license?
Apple still has feature fragmentation. Airdrop is going to be Iphone 5 or above only.
That's not relevant to developers though. Airdrop is implemented behind an activity view. Any iOS application using activity views gets Airdrop support included automatically when it is available, and they get their current behaviour when it's unavailable. They don't have to do anything to support both cases, it all just works automatically.
Compare this to an experience we had with building an application for Android recently. The client came back and asked us when we were adding certain form fields. We were puzzled - the developer had told us they were already in there. We looked at it - they were in there, but their selected/deselected state was practically indistinguishable. We talked to the developer - it looked fine to him. These were standard form controls, and they looked different on every device we had, to the point where they were invisible or defective on some. We ended up having to use custom graphics instead.
You really can't compare iOS "fragmentation" with Android fragmentation. They really are two entirely different things.
That was the point of the Apple graphic, sure, but who cares? Developers, sure, but the evidence is that that doesn't matter, because developers will follow the users.
I'm one of those developers. Developers will follow the users that are willing to buy and use our applications. There are more Android users, sure, but the users that are willing to buy and use our applications are overwhelmingly iOS users. Add in the problem of having to support ancient versions of Android, and you'll find that the cost-benefit ratio is far better for iOS than Android.
We really don't see that changing. Google aren't fixing the fragmentation problem, and the source of Android's growth - the people who don't care if they have a smartphone or not but are being upgraded to cheap Android phones - aren't a source of profit for us. In fact they are actually making the version problem worse because they are less likely to upgrade.
Already some app developers (particular game makers) are seeing Android revenues surpass iOS revenues
By "some", you mean one company with two apps, and their first app didn't even compare like-for-like.
Most Apps built for iOS5 are often a few recompiles away from running on iOS6.
No, that's not true, it would be awful if that were the case. Virtually all applications built for iOS 5 will run unmodified on iOS 6, no recompile needed. If there's an app that runs on an earlier version of iOS but not a newer version, chances are, the developers have done something they shouldn't have.
That's one of the reasons behind some of Apple's rules - e.g. you can't use undocumented APIs because they might not be there in the same form in the next version of iOS, or you can't modify an Apple control's view hierarchy because they might decide to present something differently in the future.
I suppose someone will chime in suggesting they mean the Apple TV which could be a valid point, except the market penetration of those are MUCH smaller, and the fact that they do not have any AAA titles that rival the competitors.
The market penetration is low because, right now, it's just a vehicle to play iTunes content on your television. They do not have any AAA titles because Apple hasn't opened up the SDK yet. Apple TVs run iOS internally and are roughly as powerful as their mobile devices.
Now that officially-blessed game controllers are coming to iOS 7, all Apple really have to do is open up the SDK, which will be very similar to the current iOS SDK, add internal storage, and put an App Store application on the Apple TV. Suddenly there's a ~$199 console on the market with a horde of iOS developers able to port their existing games very easily. The App Store is far easier to publish on than traditional games consoles and there's a lot of iOS developers who are champing at the bit to put their games on Apple's new game console.
Is it as powerful as the next-gen consoles? No. Can it play lots of enjoyable, cheap games with decent graphics? Yes. It doesn't have to be the most powerful console to be the most profitable console.
I assumed developers would be thinking about security first with e-commerce.
These are developers who, when faced with the problem of how to build an e-commerce site, think "I know, I'll use my favourite blogging software". Assuming they can tie their shoelaces is a stretch, let alone thinking about security.
Right about now, somebody is champing at the bit to reply saying that Wordpress has outgrown its blogging roots and is now a proper CMS. I invite anybody tempted to believe that nonsense to look at Wordpress' database schema and make their own mind up.
I think this one is likely to happen now. The reason it is currently unavailable is due to security restrictions on application processes. Apple make an exception for Safari, but they don't want to do it for all applications due to the possibility for abuse. However Apple have recently been moving parts of their system (e.g. mail composer window) over to a new internal API that lets them embed view controllers from other processes. Once they move the web views over to this system, they'll be able to grant the exception for the process that handles web views without granting the exception for all applications.
I'm personally hoping that this new architecture will be made public and provide support for greater collaboration between apps, but that might be something we don't see until iOS 8.
If you aren't talking agile with the customer, you aren't doing agile. Agile isn't a way of producing code, it's a way of producing what the customer wants. It involves them intrinsically.
When we build an app for a client, they often start off with a long list of features they want. I've seen companies take their money, go off and build what they asked for, then watch the client discover that once their users are actually using it, it becomes apparent that half the features they asked for are unnecessary and half the features they need they didn't include. A lot of the information that makes this apparent is information that is unavailable to you at the start of a project.
Instead, we focus on building the minimum feature set necessary for the client to start getting value, then see how it is used in practice, and plan the following features using this information. The client ends up getting what they really needed after all and ends up much happier.
The difference between the two approaches is that the first is traditional and the second is agile. It is also something that you cannot do on your own as an internal practice - the client needs to be involved in these decisions at each step along the way. Whether you call it agile in front of them or not doesn't really matter - you are talking agile with the customer one way or the other if you are doing it properly.
talk about outcome, not process
Talking about outcome not process only makes sense if you assume the client is not involved in the process, and that's a recipe for building something that is ill-suited for the client's needs. Agile development assumes the client is an integral part of the development process for a reason.
This leaves only the iPhone 4 and 4S as devices Apple sell without the taller screen. If there's any hint at an upcoming product strategy, it would be that they might drop those models to streamline production.
No, profiting does not inherently make something not fair use. For example, if I write a game review for a magazine and take screenshots, that magazine can be sold for a profit regardless of the fact that the screenshots are derivative works of something I don't hold the copyright to. The fact that the magazine is sold for profit doesn't stop the use of those screenshots from being fair use.
There's absolutely no way anyone can realistically claim an LP isn't a 'derivative work' under copyright
He didn't say that it wasn't a derivative work, he said it was fair use. The two are not mutually exclusive, in fact most instances of fair use are derivative works. Fair use means that you can copy a copyrighted work legally, not that it isn't copyrighted.
Just because a piece of software needs to run on an obsolete operating system, it doesn't mean that should be their main operating system. Stick it in a VM and don't attach it to the network unless necessary.
I just poked around the Stack Exchange API, and it seems several CipherCloud questions have been catapulted into the hottest questions in that site's history.
Aaaand, unless you run ALL those data samples back through the system in front of a HUMAN, then you STILL have "no idea if what you are doing is improving the situation" at all.
Yes, you do. Have you ever used Siri? There are several places where you can reliably determine that recognition was successful, due to manual confirmation or subsequent actions. For instance, if I ask Siri to remind me to do something at 9 o'clock, it might ask me if I mean 9am or 9pm. Anybody who answers either way instead of cancelling is confirming that the initial recognition of it being a request for a reminder at 9 is correct, which can be recorded as a positive result without human intervention by Apple.
Apple can store this information for thousands of accents, and when they make changes to Siri's code, they can run them against these samples to confirm that they aren't, say, inadvertently breaking reminders for people with Brummie accents when they are trying to improve reminders for people with New York accents.
If I were in charge of Siri, I'd do the same thing. That kind of real-world data is vital for regression testing. If you don't have a strong corpus of sample data, when you make changes to the code, you've got no idea if what you are doing is improving the situation for some cases, while damaging them for others. You would see people complaining about things like "Well Siri used to work for X query but now it doesn't". When you have this data, you can update the code, run the test suite, and see if it fails a large number of existing cases.
If Apple do anything to mitigate this, it will probably be some form of opt-out, but they are unlikely to make it the default, because I would imagine that building a corpus of representative speech from a thousand different accents talking about tens of thousands of different subjects is nigh on impossible otherwise, especially as jargon comes and goes so quickly these days.
The weapons in the photos look scary, but I bet they'd be really rubbish in real life. For example, the club is made from a rolled up magazine and some Liberty statuettes. It is small, not very heavy, not very sharp, and would probably fall apart if it was used.
You'd be surprised at how effective seemingly benign things like this are. It sounds akin to a Milwall brick.
Back in 2008. if you told a group of guys with Windows Mobile phones that it would be dead from Microsoft-induced suicide by 2010, you would have gotten laughed at. The original iPhone was a dumbed-down crippled toy by comparison, and Android was just a whispered rumor.
That's revisionist history. Back in 2008, everybody I knew with a Windows Mobile phone hated it. The original iPhone might have had lower specs, but it made a quantum leap forward in web browsing and people liked using it. As for Android being "a whispered rumour", the G1 was already out, I owned one, and companies were very interested in writing apps for it at the time.
It's a very responsible attitude. Guests didn't click "I agree" to the privacy violations and you can't expect them to research all that stuff when visiting. You should do them a favor and set them up with a more respectful OS
Your ISP probably has privacy clauses in their terms of service. Do you make your guests read and agree to them, or is it only an issue when they use an OS you don't approve of?
The only real bubble is that companies like Yahoo are willing to pay lots of money for one-app companies with very little tangible value. You should only really be concerned if your plan is to try to make money by creating your own app and selling it to a megacorp.
Where the money is for mobile developers is not making apps themselves, but making apps for businesses that want apps to further their non-app-related goals. It's similar to websites in the 90s - while a few outliers were people making money on websites they were building for themselves, most web developers were making money by building websites for companies to achieve their other business goals.
I've been doing mobile development for over four years now, and this whole time I've been expecting hordes of developers to descend on the market and give me a lot more competition. It doesn't seem to be happening - demand for mobile developers is still far outpacing supply. It will be a good field to be in for years to come. Eventually the mobile developer market will be saturated, but this took a decade for websites, and the people who were any good didn't care because they had the time to build up loads of experience and put themselves at the top of their field.
If you find that you do need to shift your career path, you can generalise quite easily - Java is still widely used in other areas such as server-side web development, and Objective-C will let you write native OS X applications. Generally speaking, if you can handle mobile development, you can handle desktop development with ease.
Slashdot Mirror
It's unlikely Apple would approve an application that did that.
That sounds like a recipe for an incredibly confusing user experience.
The way iOS works at the moment is that if an application tries to access something like your contacts, a system prompt pops up asking the user whether to allow it or not. If they don't allow it, the application is told this and has to handle it as well as it can. If it fails to do this well, it won't be approved by Apple. Once the user has allowed an app to access something twice or refused it twice, this preference is remembered and the user isn't prompted again.
When you pay for Spotify etc., you aren't paying a musician for their work. You're paying to copy bits on their behalf. Anybody can copy bits without permission, which is why copyright infringement is so widespread.
Paying a musician for their work involves going to see them live, or alternative business models, such as ones based on the Street Performer Protocol. In those cases, you're actually paying a musician to create music.
Could you actually read my comment all the way through instead of stopping at the first few words and assuming I don't know what a web app is? I've been writing web apps for about 15 years. You don't have to explain to me how they work.
As I stated in the comment you replied to, this is something that is explicitly excluded from copyright protection in the USA, so why do they need a license?
My question is not "hur dur, what's a web app?", it's "copyright in the USA doesn't provide them with enough power to enforce this as far as I can see, so what gives?"
Copyright doesn't cover having a copy. That's property law, not copyright law. For example: if you steal a book from a shop, at no point has the copyright holder given you permission to have that copy, yet you haven't committed copyright infringement.
Copyright covers making copies. The copies you make when using it in a web application - installing on the server, copying into RAM, etc. - are explicitly excluded from copyright protection by USA law.
How does this work in the USA? If you obtain it from them directly, they are giving you a copy, you aren't copying it yourself - so that's not copyright infringement. Copying software as an essential step in using it does not count as copyright infringement in the USA - so installing it on your server doesn't count as copyright infringement. Responding to incoming web queries doesn't copy any of their work - so that's not copyright infringement. So if you aren't doing anything that is protected by copyright, why do you need a license?
That's not relevant to developers though. Airdrop is implemented behind an activity view. Any iOS application using activity views gets Airdrop support included automatically when it is available, and they get their current behaviour when it's unavailable. They don't have to do anything to support both cases, it all just works automatically.
Compare this to an experience we had with building an application for Android recently. The client came back and asked us when we were adding certain form fields. We were puzzled - the developer had told us they were already in there. We looked at it - they were in there, but their selected/deselected state was practically indistinguishable. We talked to the developer - it looked fine to him. These were standard form controls, and they looked different on every device we had, to the point where they were invisible or defective on some. We ended up having to use custom graphics instead.
You really can't compare iOS "fragmentation" with Android fragmentation. They really are two entirely different things.
I'm one of those developers. Developers will follow the users that are willing to buy and use our applications. There are more Android users, sure, but the users that are willing to buy and use our applications are overwhelmingly iOS users. Add in the problem of having to support ancient versions of Android, and you'll find that the cost-benefit ratio is far better for iOS than Android.
We really don't see that changing. Google aren't fixing the fragmentation problem, and the source of Android's growth - the people who don't care if they have a smartphone or not but are being upgraded to cheap Android phones - aren't a source of profit for us. In fact they are actually making the version problem worse because they are less likely to upgrade.
By "some", you mean one company with two apps, and their first app didn't even compare like-for-like.
No, that's not true, it would be awful if that were the case. Virtually all applications built for iOS 5 will run unmodified on iOS 6, no recompile needed. If there's an app that runs on an earlier version of iOS but not a newer version, chances are, the developers have done something they shouldn't have.
That's one of the reasons behind some of Apple's rules - e.g. you can't use undocumented APIs because they might not be there in the same form in the next version of iOS, or you can't modify an Apple control's view hierarchy because they might decide to present something differently in the future.
The market penetration is low because, right now, it's just a vehicle to play iTunes content on your television. They do not have any AAA titles because Apple hasn't opened up the SDK yet. Apple TVs run iOS internally and are roughly as powerful as their mobile devices.
Now that officially-blessed game controllers are coming to iOS 7, all Apple really have to do is open up the SDK, which will be very similar to the current iOS SDK, add internal storage, and put an App Store application on the Apple TV. Suddenly there's a ~$199 console on the market with a horde of iOS developers able to port their existing games very easily. The App Store is far easier to publish on than traditional games consoles and there's a lot of iOS developers who are champing at the bit to put their games on Apple's new game console.
Is it as powerful as the next-gen consoles? No. Can it play lots of enjoyable, cheap games with decent graphics? Yes. It doesn't have to be the most powerful console to be the most profitable console.
These are developers who, when faced with the problem of how to build an e-commerce site, think "I know, I'll use my favourite blogging software". Assuming they can tie their shoelaces is a stretch, let alone thinking about security.
Right about now, somebody is champing at the bit to reply saying that Wordpress has outgrown its blogging roots and is now a proper CMS. I invite anybody tempted to believe that nonsense to look at Wordpress' database schema and make their own mind up.
I think this one is likely to happen now. The reason it is currently unavailable is due to security restrictions on application processes. Apple make an exception for Safari, but they don't want to do it for all applications due to the possibility for abuse. However Apple have recently been moving parts of their system (e.g. mail composer window) over to a new internal API that lets them embed view controllers from other processes. Once they move the web views over to this system, they'll be able to grant the exception for the process that handles web views without granting the exception for all applications.
I'm personally hoping that this new architecture will be made public and provide support for greater collaboration between apps, but that might be something we don't see until iOS 8.
I have never understood why so many people are so keen on putting a clock onto a website. Everyone has a clock.
If you aren't talking agile with the customer, you aren't doing agile. Agile isn't a way of producing code, it's a way of producing what the customer wants. It involves them intrinsically.
When we build an app for a client, they often start off with a long list of features they want. I've seen companies take their money, go off and build what they asked for, then watch the client discover that once their users are actually using it, it becomes apparent that half the features they asked for are unnecessary and half the features they need they didn't include. A lot of the information that makes this apparent is information that is unavailable to you at the start of a project.
Instead, we focus on building the minimum feature set necessary for the client to start getting value, then see how it is used in practice, and plan the following features using this information. The client ends up getting what they really needed after all and ends up much happier.
The difference between the two approaches is that the first is traditional and the second is agile. It is also something that you cannot do on your own as an internal practice - the client needs to be involved in these decisions at each step along the way. Whether you call it agile in front of them or not doesn't really matter - you are talking agile with the customer one way or the other if you are doing it properly.
Talking about outcome not process only makes sense if you assume the client is not involved in the process, and that's a recipe for building something that is ill-suited for the client's needs. Agile development assumes the client is an integral part of the development process for a reason.
This leaves only the iPhone 4 and 4S as devices Apple sell without the taller screen. If there's any hint at an upcoming product strategy, it would be that they might drop those models to streamline production.
No, profiting does not inherently make something not fair use. For example, if I write a game review for a magazine and take screenshots, that magazine can be sold for a profit regardless of the fact that the screenshots are derivative works of something I don't hold the copyright to. The fact that the magazine is sold for profit doesn't stop the use of those screenshots from being fair use.
He didn't say that it wasn't a derivative work, he said it was fair use. The two are not mutually exclusive, in fact most instances of fair use are derivative works. Fair use means that you can copy a copyrighted work legally, not that it isn't copyrighted.
As a developer, I think initiatives like this are important.
As a person, I can't help but think that being the person trapped inside the computer would be absolutely horrifying.
Just because a piece of software needs to run on an obsolete operating system, it doesn't mean that should be their main operating system. Stick it in a VM and don't attach it to the network unless necessary.
I just poked around the Stack Exchange API, and it seems several CipherCloud questions have been catapulted into the hottest questions in that site's history.
Yes, you do. Have you ever used Siri? There are several places where you can reliably determine that recognition was successful, due to manual confirmation or subsequent actions. For instance, if I ask Siri to remind me to do something at 9 o'clock, it might ask me if I mean 9am or 9pm. Anybody who answers either way instead of cancelling is confirming that the initial recognition of it being a request for a reminder at 9 is correct, which can be recorded as a positive result without human intervention by Apple.
Apple can store this information for thousands of accents, and when they make changes to Siri's code, they can run them against these samples to confirm that they aren't, say, inadvertently breaking reminders for people with Brummie accents when they are trying to improve reminders for people with New York accents.
If I were in charge of Siri, I'd do the same thing. That kind of real-world data is vital for regression testing. If you don't have a strong corpus of sample data, when you make changes to the code, you've got no idea if what you are doing is improving the situation for some cases, while damaging them for others. You would see people complaining about things like "Well Siri used to work for X query but now it doesn't". When you have this data, you can update the code, run the test suite, and see if it fails a large number of existing cases.
If Apple do anything to mitigate this, it will probably be some form of opt-out, but they are unlikely to make it the default, because I would imagine that building a corpus of representative speech from a thousand different accents talking about tens of thousands of different subjects is nigh on impossible otherwise, especially as jargon comes and goes so quickly these days.
You'd be surprised at how effective seemingly benign things like this are. It sounds akin to a Milwall brick.
That's revisionist history. Back in 2008, everybody I knew with a Windows Mobile phone hated it. The original iPhone might have had lower specs, but it made a quantum leap forward in web browsing and people liked using it. As for Android being "a whispered rumour", the G1 was already out, I owned one, and companies were very interested in writing apps for it at the time.
Your ISP probably has privacy clauses in their terms of service. Do you make your guests read and agree to them, or is it only an issue when they use an OS you don't approve of?
The only real bubble is that companies like Yahoo are willing to pay lots of money for one-app companies with very little tangible value. You should only really be concerned if your plan is to try to make money by creating your own app and selling it to a megacorp.
Where the money is for mobile developers is not making apps themselves, but making apps for businesses that want apps to further their non-app-related goals. It's similar to websites in the 90s - while a few outliers were people making money on websites they were building for themselves, most web developers were making money by building websites for companies to achieve their other business goals.
I've been doing mobile development for over four years now, and this whole time I've been expecting hordes of developers to descend on the market and give me a lot more competition. It doesn't seem to be happening - demand for mobile developers is still far outpacing supply. It will be a good field to be in for years to come. Eventually the mobile developer market will be saturated, but this took a decade for websites, and the people who were any good didn't care because they had the time to build up loads of experience and put themselves at the top of their field.
If you find that you do need to shift your career path, you can generalise quite easily - Java is still widely used in other areas such as server-side web development, and Objective-C will let you write native OS X applications. Generally speaking, if you can handle mobile development, you can handle desktop development with ease.