4,570 karma · joined August 28, 2011
More about me at http://milen.me/
In the mean time, you can just use the free beta (it will run for at least a few months).
We've got tons of upcoming improvements and features, the launch of the beta is only the beginning of a much longer journey.
If you have any suggestions or ideas, just add a comment in this thread or get in touch. I'll try to answer anything that comes up, so fire away :)
_____ _ __ __ _ _
| ____|_ __ (_) ___ _ _ | \/ | ___ _ __ ___ __| |_ __ __ ___ _| |
| _| | '_ \ | |/ _ \| | | | | |\/| |/ _ \| '_ \ / _ \ / _` | '__/ _` \ \ /\ / / |
| |___| | | || | (_) | |_| | | | | | (_) | | | | (_) | (_| | | | (_| |\ V V /|_|
|_____|_| |_|/ |\___/ \__, | |_| |_|\___/|_| |_|\___/ \__,_|_| \__,_| \_/\_/ (_)
|__/ |___/Furthermore, if you're UK based and use a non-UK marketplace / reseller, then the revenue you receive from the reseller lies outside the scope of UK VAT and you don't have to do anything [1]
The reason why most EU developers on the App Stores don't deal with VAT is because the vendor of record is Apple Luxembourg, thus lies outside the scope. And that's precisely why Apple requires VAT invoices from Luxembourg-based developers.
[1] https://www.gov.uk/vat-how-to-work-out-your-place-of-supply-...
I think one aspect that gets easily lost in the debate is the long-term impact of having your app on the MAS (exclusively or not). You need to consider the value of being able to provide trials (i.e., do not force potential customers to spend money upfront on software that might not fulfil their requirements), discounts for your long term repeat customers, the ability to communicate directly with them and resolve their problems.
If you want to run a sustainable business, whether the MAS is a net positive becomes a question mark. I have not seen much supporting data to suggest that the MAS is a net positive if we compare exclusive direct vs exclusive MAS over a long period of time.
Anecdotally, from the data I have on hand (conversations with customers and friends), almost no one discovered their Mac apps from the MAS (there's some bias in my sample, of course). If they needed the software, they would have bought it - whether it's outside or not doesn't matter. If you need a tool for your job (the type of software I'm interesting in making), you're not going pass on it just cause you have to enter your credit card. For other types of software, the more disposable ones, convenience plays a much bigger role.
And most importantly of all, it will all depend on the particular type of software that you're selling. In my experience, the MAS works great for type of software that's mostly consumable - cheap, disposable, no long term plan to keep it updated. For other types, where you plan to run a sustainable business over many years - I'm not convinced.
While you'll probably do less units selling directly, you'll be getting a significantly higher proportion of the sale price. It's important to consider all aspects, not just raw revenue over a short period of time and make a decision from there - for some apps, the MAS would be the right way, for others - not so much. Now, deciding which way to go is a much, much harder question and I'm afraid there's no easy way to come up with a definitive answer.
While it's not the end of the world, it's just plain annoying having to remove such a common sense feature. The consequence of this means that if you were to distribute a web browser via the MAS, you will not be able to ask the user to set it as the default web browser. That's just a subpar experience.
My hypothesis for the added restriction is that it might be considered a security hole for an app to just set itself as a handler, for say, http links.
The correct way to have handled this particular situation was to introduce a new entitlement and define what content types an app might want to handle, which will get reviewed by the MAS review team. Unfortunately, the solution [2] is: "There is no solution; it can't be done anymore in the sandbox."
[1] http://stackoverflow.com/questions/26241689/lssetdefaultrole...
That doesn't follow. Sandboxing privileges present a wide spectrum ranging from providing no entitlements on one end to providing an "allow anything" entitlement on the other. Obviously, as developers, we want as much functionality exposed in a secure way but the unfortunate reality is that Apple either do not have the resources or willingness to do so.
> However, Mac apps are not required to be sandboxed. Only apps distributed on the MAS are.
While that's technically true, an argument can be made that due to the inclusion of the MAS as part of OS X, it's practically required for an app to be on the MAS as that's where a lot of the users are and it's how they get their software.
> Can you give examples?
Yes, Coda 2.5 [1] was not released on the MAS due to sandboxing issues. There are some radars on openradar [2] referring to other sandboxing issues, too - some of them are reasonable. Obviously, I do not have access to Radar itself otherwise I would have provided more examples.
> But that's not even remotely a trivial task.
I don't see that as a valid excuse for not providing an API while at the same time rejecting the usage of a temporary entitlement due to lack of said API. It's a given that providing functionality in a sandbox compatible way would not be trivial - the work needs to be done if we want everything to be nice and secure. I'm perfectly aware that the effort required to implement such an API would be considerable and it might not be worth it but that doesn't make it the right approach. And that's why I accept the current situation - it's a compromise between what could be and what Apple have decided to implement at present.
> Others would require massive work.
Yes and in an ideal world, if we're fully committed to sandboxing, that work would be done. You said:
> Apple developed the OS that you're using, so there's hardly a trust issue when talking about running applications from Apple on top of the Apple-developed OS.
Sandboxing is not just about trust, it's also about security. Apple's own software not being sandboxed means its vulnerable to exploits, exactly what sandboxing is trying to prevent. If you check Activity Monitor, you will see plenty of Apple and others' apps being non-sandboxed - all of these are potential targets. A system is only as secure as it's weakest link, so if we want a more secure system, we should working towards having more sandbox entitlements.
As a side note, the trust side of things is taken care of by code signing.
> And implied that this means Apple should allow third-party apps to continue violating rules because the existing experience of using that 3rd-party application somehow trumps everything else.
No, the implication is that Apple should be working towards exposing more functionality in a secure, sandbox compatible way.
[1] http://www.panic.com/blog/coda-2-5-and-the-mac-app-store/
The argument that I've been making for years is that proper entitlements should have existed for all the functionality necessary before the requirement for all apps to be sandboxed was introduced.
> The only really useful thing to actually try and get Apple to change is to expand the sandboxing capabilities to allow certain things that 3rd-party apps want to do and cannot do today. They've added more and more capabilities over time. The question is what functionality can be effectively exposed to sandboxed apps without opening up a security hole.
Exactly, that's what should have been happening and has been to some extent but not aggressively enough. Part of the problem is that a lot of things pose no security threats but there are still no way to access that functionality in a sandboxed app - that's the crux of the problem.
In the case of GaragePay, it used an external utility to deal with encrypted disk images. The app has already been given access to the file via the powerbox [1], there is no additional security threat. Unfortunately, there are no APIs to operate on such disk images except the external hdiutil utility. The correct way to have resolved this was to expose APIs to access that functionality or else allow a temporary exception until such APIs exist.
> That functionality should never have been in the MAS app to begin with.
Why shouldn't it be? In almost all cases, the functionality can be sandboxed if Apple provided an API to access it securely but there just isn't a entitlement for those cases - not because it's not possible but because it's just not implemented.
> Also note that the claim "Apple shouldn't apply that rule, because it removes app functionality, and that's bad for users" is quite ridiculous.
I never claimed that. I only claimed that removing functionality objectively leads to an inferior experience due to the lack of said features. In an ideal world, the correct way to have gone about it would be to provide the necessary security mechanisms to make that possible. While Apple did add additional entitlements over the years, there are still many operations that reasonable and do not pose a security threat that are still not supported.
> If your app requires violating app store rules for certain functionality, then you shouldn't be using the MAS as your distribution channel.
While that's true a statement, that's not the crux of the problem. The root issue is that if the required entitlements were available, then the app wouldn't be violating any rules at all and we wouldn't even be having this conversation.
The concern is that if you want to ship software on the MAS, like some of Apple's, that requires certain functionality which does not have a way to be accessed if you're sandboxed, then you cannot - while Apple can. As I mentioned multiple times, it's Apple's platform, they make the rules and can do whatever they want but this means that there are certain classes of software that cannot be distributed via the MAS by 3rd parties, only by Apple as they are not bound by the same rules.
> What does? You're being a bit unclear here so I don't know what you're referring to with "it" here.
The request to remove functionality due to (M)AS rules leads to an inferior experience for customers, as those customers can longer access that functionality.
> Apple being exempt from sandboxing restrictions leads to a worse experience for customers? Doubtful.
I don't know how you came up with that, it was never said nor implied in any way whatsoever.
> What do you mean, without leaving them a choice?
It means that if you want to distribute via MAS, you have to cripple (or remove) part of your app's functionality in order to pass review. Again, nothing inherently wrong with that but the net effect is that your software might be inferior when distributed via the MAS vs outside.
While the tastefulness of that solution might be questionable, I believe users should be able to decide for themselves whether it's acceptable or not. Of course, this is Apple's turf and they can make any decisions they like. Note that lots of users quite liked Neato - should we be making decisions for them?
The real question is: where do we draw the line? Different people will have different opinions but I think most people would agree that the Panic situation, Drafts getting asked to remove their widget while others had the exact same functionality is not acceptable.
The examples I listed demonstrate a problem that's endemic on the App Store - while we might disagree on particular rejections, it's quite obvious there are issues.
With regards to the sandboxing issue on the MAS, it's relevant because Apple are themselves exempt from the restriction to ship sandboxed apps - this is hypocritical. Moreover, it objectively leads to a worse experience for customers, which I feel is against both Apple's and developers objectives. It's an example how the MAS effectively cripples 3rd party apps without leaving them a choice, while 1st party apps enjoy special privileges. Again, there's nothing inherently wrong in Apple making the rules - it's their platform after all but developers need to be aware what they sign up for when they decide to distribute their software on the MAS.
---
Responding to your updated post:
> ... But there are also plenty of valid rejections too (many orders of magnitude more). And it's a mistake to think that every publicized rejection is invalid.
Of course, I totally agree with you. I don't think anyone is arguing that every publicised rejection is invalid - I was trying to make the point that we're seeing increasingly questionable rejections that a lot of people would agree are hurting the platform itself.
I've had enough of this stuff and I've voted with my feet - I no longer develop for iOS and I'm back to the Mac, outside the MAS.
My absence won't make any difference to Apple but it makes a huge difference to my wellbeing and health by not having to deal with this stuff. It pains me so much to see fellow developers' efforts just thrown down the garbage bin. It's extremely demotivating to have your work crippled when you're striving to create the best software. The reason why this keeps happening and will continue is simple - there are hundreds of thousands of people developing for iOS, it's Apple's playground and their rules - if you don't like it, you can leave. If you're an indie, you have zero leverage, that's the reality. I honestly hope things improve in the future but until that happens, I'm done with it.
A few recent examples where the (Mac) App Store cripples apps:
- Drafts get asked to remove widget while other widgets to do the exact same http://www.macrumors.com/2014/12/02/apple-drafts-widget-remo...
- Rejected for slide to start, which is a gesture not even used anymore: http://mjtsai.com/blog/2014/11/25/racesplitter-rejected-for-...
- Sandbox forces feature removal http://mjtsai.com/blog/2014/12/02/garagepays-encryption-remo...
- Notification Center rejection http://www.macrumors.com/2014/11/18/apple-cracks-down-on-nea...
- PCalc got asked to remove calculator but then decision reversed http://www.macstories.net/ios/apple-asks-pcalc-developer-to-...
Unless Apple provide a multi-cable solution for the 2013 Mac Pro when the 5k Thunderbolt display comes out, you won't be able to take advantage of 5k displays on it.
My prediction is that we'll see an updated Mac Pro that also uses the Haswell Xeons (2013 Mac Pro uses last gen Ivy Bridge) and also DP v1.3 (which can support 5k displays).
DisplayPort v1.3 can deliver 25.92Gbps of usable bandwidth, thus required for 5k [1].
[1] http://www.extremetech.com/electronics/190130-displayport-1-...
DisplayPort v1.2 can carry around 17.3Gbps (this is minus overhead), so you would need DP v1.3 with an effective rate of 26Gbps to support native at 5k without compression [1].
[1] http://www.extremetech.com/electronics/190130-displayport-1-...
My predication is that once we see Apple deploy Thunderbolt 3 / DisplayPort 1.3 (capable of 25.9Gbps usable bandwidth [1]), we'll see the Apple Cinema Display Retina.
[1] http://www.extremetech.com/electronics/190130-displayport-1-...
If I were in the market for the Mac Pro and could afford to postpone, I'd wait until the next update which should get the latest Xeon processors with the new socket and Thunderbolt 3 (which will be used for Broadwell Xeons).
My predication is that once we see Apple deploy Thunderbolt 3 / DisplayPort 1.3, we'll see the Apple Cinema Display Retina.
I've been creating software for many years, I'm well aware that feature requests that look quite simple on the surface can require significant development efforts.
Having said that, implementing trials / upgrades is no a technical problem per se, it's more a question of spending the development resources required (yes, obviously there will be assumptions in the whole infrastructure that would require a bit of work but nothing that should have taken years to implement). In-App-Purchases were introduced a few years into App Store's existence, so it's certainly possible for them to implement major features when the willpower exists (and I'd wager implementing trials / upgrades would be easier than IAPs, although that's my guess, I have no internal information).
In any case, I very much doubt the reason for not having those features implemented is because they don't have the available development resources - it's more likely a decision was made that those feature do not align with Apple's vision of how the MAS should work.
I have two questions for you:
1) Who is the vendor of record? This is relevant to handling VAT and it means either you have to do it or the business selling the software.
2) I couldn't find any information on what countries are supported, payment methods for receiving royalties, etc.
Thanks.
Note that while the notion of paying once and getting infinite updates forever is quite nice, it's not rooted in reality. Either the app you're using will get abandoned or you will have to pay up at some point in the future, somehow - ads, IAP, etc.
For example, there might be 4-5 apps in the $30-50 range that I want to try. I'm not going to spend $150 and then having to request a refund for the rest - it simply won't happen.
1. I totally agree with you on this point - the MAS is a fine store for something that costs $1-10 and maybe took only a few months to develop, maybe a hobby project. But building a serious business for apps that cost $30-50+ is much harder - it's possible but it won't be ideal (talk to the developers behind the apps in those categories). The point behind the article is that it doesn't have to be that way, the tools can be easily made available.
2. Only if you're the selling directly to customers (and even then it's not a massive deal as you can just signup for the VAT MOSS, which means you only deal with a single VAT entity, which you have to do if your sales exceed the VAT threshold). Furthermore, if you sell via a reseller, your sales lie outside the scope of VAT (as the sale is technically made by the reseller). For example, that's the case with FastSpring, as they're a US company and you will be receiving proceeds from them (assuming you're in the EU). FastSpring themselves handle all VAT related issues (they comply with all EU laws and will pay it out) - you don't have to lift a finger.
Note that there are some very large difference between the software on iOS and Mac. On mobile system, the vast majority of apps are more akin to small consumables - like having a can of coke or a cup of coffee.
On the Mac, you have much more complex software, that can take years (and even decades) to develop. This software requires serious investment of resources and time. If the ecosystem cannot support it, it won't exist.
You're right that the iOS store is designed to encourage a lot of choice at low prices - that's what sells iPhones. This might be okay for consumables but a non-starter for professional software that exists on the Mac.
What's worse, as you say, is that there's absolutely no indication that some of those apps have been abandoned (apart from the very old Last Update date). The vast majority of consumers will just buy the software and not go researching whether the app they're acquiring has been left collecting dust.
And at the end, both consumers and developers lose out.
You're quite right that the convenience is part of the big pull of the MAS. But as you say, this can be implemented separately. If you can get the critical mass with some major players behind it, it can become a standard in no time.
The security issues related to sandboxing are not insurmountable, either. We can have both sandboxed apps that have wider accesses so that we don't restrict the freedom of users.
2. Sorry about that, the issue seems related to the font metrics which results in the robot looking misaligned. We'll fix that it in the next few days. Here's how it should look correctly - http://imgur.com/pst21UO
In general, the best way to have your voice heard would be to drop us an email, so that we can have at least some quantified data - thanks.
I've got nothing against web apps, I use some on a daily basis - they have their own set of advantages over native apps.
But for the purposes of Monodraw, I wanted to provide the absolutely best user experience. I want 60fps with tons of elements on screen, I want to be able to tap into the OS and integrate with it. Our auto-tracing code would take advantage of all your computer's cores. I even wrote my own custom text layout engine and now you can do some really cool things with it. I love the interactivity and fluidity of native apps.
You're absolutely right that once you have the app, it's yours to keep. Our proposition is simple - we will charge for the software and our users / the market will decide whether it's financially viable. Our job is to make an outstanding product that delights customers.
1) Why Mac? Because I'm an Mac / iOS developer and I know Cocoa. I have no experience programming for Windows (e.g., MFC, WinForms, WPF) nor Linux (GTK+ / Qt - I dabbled a bit many years ago but that's about it).
2) Why not use a cross-platform toolkit? Fundamentally, a cross-platform app is at odds with our core value - providing the best user experience. In practical terms, this means we have to use the native toolkit for the platform. While it is true that you can use a cross-platform toolkit, the experience will never be as good as it can be. Moreover, not only do I lack experience with such toolkits, if we want to make a cross-platform app, we would want it to feel native on all major OSs. This involves an incredible amount of work and resources that we do not have.
It all boils down to the fact that we want to make the best app for the platform that we have experience with.
Hope that clarifies the reason why it's Mac-only.
I'm also playing with the idea in my head of collaborating with some Windows developer to make it happen, although it's nothing more than just a thought. If any Windows developers are interested, please get in touch - thanks :)
The user experience comes first, no compromises. But please note that I'm not saying that I'll drop support for 10.9 because there's some convenient API on 10.10 that will save me a few days of work. 10.10 would be a requirement if and only if it provides a meaningfully better experience.
I also think some developers might start requiring 10.10 for their next major versions, assuming they have been designed in line with Yosemite's new visual language. Supporting both < 10.10 and >= 10.10 UI-wise would involve non-trivial amounts of work, would for most small indies would be impractical.