So,you've pretty much established yourself as an expert in the ecosystem. That actually lends less credence to your counterarguments in my eyes. It's all too easy as an expert to overlook the pain points that you've become accustomed to, or did not notice as they were slowly layered up over the years. In my experience, the expert that rages against the system they use is far more likely to have valid input than the expert that apologizes for it.
That's not to say you're wrong. Just that in my eyes the likelyhood of you being right dropped as you explained how much experience you had (past a certain threshold. Amateurs often don't understand enough to accurately critique as well).
Same holds for the inverse: it's easy as a newb to consider everything as a pain point, even if it's a well designed procedure.
Sure, that's why I noted as much with my last sentence. :)
Seriously if your app gets rejected that much that you'd bitch about it, it's because you're not paying attention to what you're doing and/or are up to some shady shit. It's really not difficult to avoid.
I'm not saying JS doesn't have more general use constructs but HMTL/JS always feels like a strange, uncomfortable way to describe native UI. I guess what I'm saying is that you tend to feel the compromise.
In the end, I just think the language and tools used by the teams that build core apps for a platform will always beat those designed to abstract away what makes the platform special and compelling.
Instead of a common standard we have 3 competing stacks.
Having developed several hybrid and native apps on both platforms, I can say that usually the worst layouts are done by devs with experience only in one platform. From a high level, it's easy to accomplish the same thing on all platforms, animations included. It would be a ton easier if they just would actually converge.
Storyboards and xib files use XML as a serialization medium, but you never actually work with the XML directly, it's literally just an underlying file format and the only reason it's used over a binary format is to make VCS merge conflicts easier to deal with. And more importantly, the actual built iOS app does not contain XML. Instead the build process constructs the view hierarchy based on the storyboard/xib (just as the interface builder editor does) and then serializes that to a binary plist (this is why UIView and UIViewController conform to NSCoding).
None of that changes this fact for me: JS/ES is completely irrelevant to me as a development language. I've learned a bit and found portions reminiscent of a few other languages, but I don't really have a practical use for it, myself.
All cyclists should know the basics, but nobody falts them for choosing not to ride a tricycle once they can choose between tricycles and bicycles. Or choosing to use a tractor trailer instead of a bike if that's what they need.
Boyancy is the foundational concept of naval transportation, but it's not the foundational concept of all transportation.
[*] Not sure if I was right before or after, check back in a few years :)
In Android, our beta users download the app from the Play Store just like normal. The app automatically updates and for them, performs basically exactly like a normal app. On iOS, every update has to be a manual intervention for a beta user.
Look, the whole point of our beta community is to get early testing on new code. If half or more of the community put off updating for a few days because it's an annoying process, that's the exact opposite of useful. And it's worse than that -- I have no doubt that a great many of our beta users are now significantly behind our normal production users, because normal production users get automatic updates and beta users don't.
Almost entirely avoided still means you have to go out and buy a Mac and keep Xcode running on it.
I understand that some of these EULAs aren't enforceable everywhere, in the form of consumer protection laws inhibiting what's basically perceived to be bullying behavior. At least in the U.S. consumer protection laws are weaker, depending on the idea that when consumers are bullied, they'll spend their money elsewhere.
In a global market, asymmetric consumer protection laws aid bully behaviors. The countries were people are safe flaunting EULAs may have higher usage rates of software with unfavorable EULAs, rather than using alternatives with a more favorable EULA.
I totally understand not liking the license, but if you click the agree button when installing the software on non-Apple hardware, you're basically lying.
If you acquired Mac OS X legally how would this be illegal? I will admit acquiring it legally could be tricky, but that is not what we were calling illegal was it?
The (mostly-untested) theory is that clicking "I agree" on the license is a legally-binding contract between you and Apple. The Mac OSX license repeatedly says that a requirement of the use of the software is that it be used on Apple-branded hardware.
So, "illegal" based on unlicensed use of copyrighted material or based on breach of contract. At least, that's how I understand the argument.
Seriously, I can never take this argument seriously.
I can easily develop iOS software without owning an Apple computer...but I can't do it legally. I'm happy I'm not in mobile dev, and this is one reason.
Yeah if it's just Swift/ObjectiveC vs HTML/JS/CSS, then it's a moot point, just pick one.
However it's Swift/ObjectiveC/Java(Andorid) vs HTML/JS/CSS
The latter comparison is not even equivalent.
> Provisioning Profiles
Provisioning profiles are still an annoyance if using tools such as Jenkins to compile and distribute builds, as xcodebuild has to be used to build the app. This forces you to manually set up the profiles and consequently run into many of the problems that have been solved with automatic signing. This also affects ad-hoc deployment as the process of adding new testing devices requires the generation and download of a new ad-hoc provisioning profile onto the Jenkins machine.
>Without the author listing the reasons for rejections it's hard to draw a conclusion here but complaints about rejections are usually BS.
I don't think this is the case of all apps. In the past few months my company has easily over ten rejections, due to the fact that our app targets a niche that the reviewers are not knowledgeable on. For instance, we received two rejections in the last month over the wording of our background location services requests. We use industry specific keywords that reviewers did not know, but users of our apps most definitely would know. It is true that these issues are generally sorted out easily, but we still receive rejections and it can get frustrating.
Regardless, the author stated he received 7 rejections before being approved. It seems to me that if the author's app was rejected this many times, he failed to follow Apple's app review guidelines in some form (Complete conjecture of course).
Yes, there's an appeal process, and yes, it's much faster than it used to be. But it has happened enough that I can't confidently predict how long an update might take because of uncertainty with the review process.
Not a terrible assumption. There are way more web devs than any others.
>> There are some major advantages to the Hybrid approach: You get to utilize your existing JS, HTML, and CSS skillset to develop a single codebase that runs on both iOS and Android.
This is assuming you have a JS/HTML/CSS skillset.
>> Here’s some Apple BS we can’t avoid no matter what approach we use >> Xcode
I've done some React Native development and Xcode is almost entirely avoided.
>> Provisioning Profiles
It's been a long time since I encountered issues here as it's all managed by Xcode nowadays.
>> Needing to use TestFlight for beta builds
Why is this BS? You could also use Ad-hoc distribution along with something like Fabric for small scale beta tests.
>> The app review process. Admittedly, the app review time has dropped to about 2 days on average, but when your app gets rejected 7 times like Rizer did (for legitimately silly reasons), your patience can really start wearing thin.
I've been developing on iOS since about 6 months after the App Store became a thing. I've developer dozens of apps and submitted hundreds of updates. I can count on my fingers the number of rejections I've got and there were only one or two that were 'silly' (and those were fixed through a quick appeal). Without the author listing the reasons for rejections it's hard to draw a conclusion here but complaints about rejections are usually BS.
Overall I can't help but feel this was thinly veiled clickbait to advertise the authors app.