iOS is relatively young. It attracts a lot of new programmers. For years iOS suffered from lack of ideas around architecture and solid programming practices.
In the last few years I've seen this start to change and now it seems a bit like "ARCHITECTURE ALL THE THINGS!!!". We're in a period of trying out new ideas and figuring out what works and what doesn't.
Give it a few more years and these ideas will start to mature.
One workaround is to change your business model and accept donations instead. That obviously won't work for everyone, obviously.
This works because tips and gratuities are not considered taxable consideration for VAT purposes and therefore outside the scope of VAT. It has to be a genuine tip though - i.e. voluntary, no minimum or recommended amount and not a condition of purchase.
There is a platform out there that lets you sell things under this model but I can't remember it's name.
Yes, B2B sales between EU countries are handled using the reverse charge system, when the supply is where the customer belongs - subject to certain use and enjoyment provisions (e.g. If a UK business sells software to a German business for use in the German business's UK office it would be subject to UK VAT instead).
As I mention in my post below, if you're a non-EU company selling digital goods and services to EU customers, then strictly speaking these new rules don't change much - it's was already the case that non-EU suppliers that supply electronically supplied services to EU customers (B2C transactions, not B2B) should be charging the customer VAT at their local rate.
Businesses could choose to register in each state or a single one using the VoES (VAT on e-services) system. These rules have been in place since 2003.
However I imagine that a lot of non-EU companies didn't bother with this either out of ignorance or simply because they didn't care or thought it could be enforced.
Under these new rules, MOSS replaces VoES but it's practically the same thing. This mostly affects EU businesses who now have to charge the rate where the customer belongs, not where the supplier belongs.
On digital goods and services. I'm pretty sure the liability to pay VAT on physical goods, along with any import duty, is the customers when the item is imported.
For the record, here's the HMRC (UK revenue service) explanation of the special VoES scheme that's been around for ages:
US/non-EU companies selling digital products and services to the EU is most certainly NOT exempt, and it wasn't exempt before these recent changes - it's been a requirement that US/non-EU businesses selling digital services register to charge VAT to EU customers at their local VAT rate since 2003!
Rather than registering in each EU country, they could register in one country and use the VoES system to submit their returns.
It was because of this ruling that big companies like Amazon found a workaround by setting up subsidiaries in countries with low VAT rates like Luxembourg and sold their goods from there. This meant they could charge Lux VAT instead of the customer country's VAT rate.
This obviously gave them an unfair advantage not only over local businesses but also non-EU businesses that used the VoES system.
In effect these new rules change little for non EU businesses. The VoES system is being retired in favour of the new MOSS system which is effectively the same sort of thing, only now, ALL businesses including those in the EU, have to charge local VAT when selling digital services to the EU.
For e big companies like Amazon, this closes a loophole. For those who were correctly charging VAT under the VoES system, nothing much changes. For those non-EU companies who were chose not to comply with the 2002 rules, well I'd imagine they will continue to not bother. And those who were ignorant of them (many I'm sure) might now be a bit more aware.
But of course the businesses it affects the most are small EU businesses who now have to charge different rates of VAT or use MOSS when they didn't before.
Other than adding dozens of methods to NSArray/MutableArray for each "generic" you define and limiting my choice of collection to an array (rather than a set or dictionary), why would you use this rather than define your own collection class that keeps the underlying store encapsulated and enforces its own type-safety?
If type-safety is that important, a custom collection class will enrich your domain model and be more obvious.
I know Pointfree do script their episodes but I can’t say I’ve ever noticed it in any detrimental way.