9 ms·

Where to start? >> There are some major advantages to the Hybrid approach: You get to utilize your existing JS, HTML, and CSS skillset to develop a single code

• TillE 9y ago
  The idea that everyone a) knows Javascript/HTML and b) likes Javascript is astonishingly insular. The web is not the world, and you really shouldn't try to crowbar it into literally everything.
  • ElijahLynn 9y ago
    JavaScript is the future. All devs should know the basics.
    • thehardsphere 9y ago
      It's the future of parts of the web, not the future of everything. 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.
      • ElijahLynn 9y ago
        JavaScript is the foundational language of the web. You can't build anything reasonable on the web without JavaScript. As far as I can see it will be with us for at least another 20 years.
        • thehardsphere 9y ago
          The web is not everything. Boyancy is the foundational concept of naval transportation, but it's not the foundational concept of all transportation.
    • valuearb 9y ago
      I thought webassembly was the future?
    • khedoros1 9y ago
      Javascript is the present, and only part of the present. It's completely irrelevant to my area of development.
      • ElijahLynn 9y ago
        I foresee JavaScript being with us for the next 20 years whether we like it or not. It is the language of the web. We may have transpilers of all sorts but it will always come down to JavaScript at the base.
        • buzzybee 9y ago
          Nope. Replaced by WASM within 5.
          • ElijahLynn 9y ago
            That statement means we will all be using Web Assembly to manipulate the DOM...and then to do any scripting we will just be writing WASM? What am I missing here?
        • khedoros1 9y ago
          Javascript may be around, as a compatibility layer at the very least. I tend to agree with the sibling comment, though: WASM at the base, compiled from Javascript (and just about every other language you could want). WASM isn't something you'd be likely to hand-code, it seems like. 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.
    • jbigelow76 9y ago
      I used to think that* but began re-evaluating it when I found out how much of the world's population first computer is/was a smart phone. The inevitability of a language originally tied to a web browser optimized for desktop computers seems a whole lot less certain to me now. [*] Not sure if I was right before or after, check back in a few years :)
  • toddmorey 9y ago
    Also, I think the idea that Javascript and HTML, languages designed specifically to markup and manipulate web documents, are the right tools for native app development is misguided as well. 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.
    • doublerebel 9y ago
      Both Android and iOS majorly use XML to describe layout, and constraint-based layout on both platforms is essentially flexbox (CSS). 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.
      • eridius 9y ago
        iOS does not use XML to describe layout. 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).
• jordache 9y ago
  >>This is assuming you have a JS/HTML/CSS skillset. 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.
  • ido 9y ago
    There are plenty of multi platform solutions that do not require you to write native objc or Java.
• robert_foss 9y ago
  > I've done some React Native development and Xcode is almost entirely avoided. Almost entirely avoided still means you have to go out and buy a Mac and keep Xcode running on it.
  • sams99 9y ago
    sort of, I run a VM on Windows using VMWare workstation, involves binary patching the vmware executable, but hey, cheaper than buying a mac.
    • mixedCase 9y ago
      Also illegal, so not a solution for non-hobbyists.
      • Teever 9y ago
        I don't think it's illegal in my country. Or most of the world really.
        • cmurf 9y ago
          Technically it's not illegal as in criminal, but it is a violation of the contract you're agreeing to in the form of the software license. And the macOS software license only permits running macOS on Apple hardware (it can run in a VM, but the VM host must be Apple hardware). 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.
          • ElijahLynn 9y ago
            Another reason Apple is BS. "macOS software license only permits running macOS on Apple hardware", I disagree with Apple so hard here. What a scam.
• kbenson 9y ago
  > 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). 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).
  • k-mcgrady 9y ago
    I understand your point but I think length of time developing for the platform (in this specific example) is important. Based on my experience (and I'm willing to bet if there is a large set of data available on rejections it would back me up) 7 rejections is extreme leading me to believe something is up on the authors end, not Apple's. A 5 min glance at the App Store guidelines will prevent 99% of rejections. Skill doesn't really come into avoiding rejections (besides bugs in your code of course).
    • cptskippy 9y ago
      The guidelines are very nuanced and reviewers are free to interpret them as they see fit. We have had an app in the store for over 2 years that jumped through hoops to avoid the 30% Apple Tax to accept a charitable donation in app. Our Apple account Rep reached out to our marketing director in the fall of last year to tell us the policy changed and that we wouldn't have to do stupid shit anymore. So we spent Nov and December developing a much improved experience. It was submitted, approved and has been available in the store since before Christmas. This week we received notification that our app violated the guidelines with regards to that specific feature and we had 2 weeks to fix it.
  • 9y ago
• aetherson 9y ago
  At Life360, we've started really seriously using the beta programs for both iOS and Android, and I've got to say that the iOS experience is terrible in comparison to Android. 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.
• ojr 9y ago
  I've done React Native, it is beta but Ive dealt with XCode builds breaking when upgrading versions multiple time, also XCode builds need to pass and bad builds are not hard to come by, fixing XCode builds can be painful, for example you have to download multiple gigabytes of Xcode to support the latest iOS version, Android isn't that much better to be honest, but shipping makes it all worth it!
• greenhatman 9y ago
  >This is assuming you have a JS/HTML/CSS skillset. Not a terrible assumption. There are way more web devs than any others.
• patwolf 9y ago
  Even one 'silly' rejection is enough for me to consider the review process problematic. I've seen the same app pass review many times, and then suddenly it's rejected after a routine bug fix or minor update. 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.
• cptskippy 9y ago
  Working with a team of 5 developers and a rotating group of 10+ testers using personal devices, I can assure you provisioning profiles and certificates are a huge pain in the ass.
• hunnefeldtyler 9y ago
  I agree there are quite a few problematic areas of this article (It reads like a advertisement for the author's app to me also), but a few of the negatives he listed are issues I've encountered in my career in iOS Development, albeit a career much shorter than yours. > 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).