Deprecated: Return type of I::current() should either be compatible with Iterator::current(): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /home/public/kirby/toolkit/lib/i.php on line 62

Deprecated: Return type of I::next() should either be compatible with Iterator::next(): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /home/public/kirby/toolkit/lib/i.php on line 91

Deprecated: Return type of I::key() should either be compatible with Iterator::key(): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /home/public/kirby/toolkit/lib/i.php on line 71

Deprecated: Return type of I::valid() should either be compatible with Iterator::valid(): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /home/public/kirby/toolkit/lib/i.php on line 101

Deprecated: Return type of I::rewind() should either be compatible with Iterator::rewind(): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /home/public/kirby/toolkit/lib/i.php on line 53

Deprecated: Return type of Collection::count() should either be compatible with Countable::count(): int, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /home/public/kirby/toolkit/lib/collection.php on line 80

Deprecated: parse_str(): Passing null to parameter #1 ($string) of type string is deprecated in /home/public/kirby/toolkit/lib/url.php on line 135
One Tap Less | Why Apple should relax its App Store rules

Why Apple should relax its App Store rules

Marco Tabini for Macworld:

On the other hand, I think that it’s time for Apple to figure out how to relieve some of the most pressing pain points that developers keep encountering. As a user, I’m much happier if developers can focus on building better features instead of having to reinvent the wheel for features like synchronization and inter-app communication. And as a developer, I’d much rather not waste my time on things like building my own user management or payment system, or be forced to offer an inferior experience to my users because of the fickle policies that Apple decides to enforce.

My biggest concern with Apple reviews is how irregular they’re. Looking at the recent struggle Isaiah is having to push the next version of Favd into the App Store, it is easy to think that sending an app for review relies more on the mood of the reviewer than the actual rules.

www.macworld.com