10 ms·

Occasionally I'll write an app for my kids or wife. Every time I'm thoroughly impressed by the Apple development ecosystem and thoroughly disgusted by Google's

by sidlls 9y ago

Occasionally I'll write an app for my kids or wife. Every time I'm thoroughly impressed by the Apple development ecosystem and thoroughly disgusted by Google's for Android. This is no different. The Android development process is painful (the most verbose, cruft and boilerplate filled Java), cumbersome to organize and build (Gradle is terrible, and buggy) and debug (the integration with Studio is just clunky). About the only thing Google does better is testing releases through the developer console. It's nice to see them finally providing something similar to ARKit. I just wish they'd work on all the other things that make Android development a horrible experience.

dannyr 9y ago
Android Studio/IntelliJ is an excellent IDE. Kotlin is a great language. There's Instant Run for quick builds. I've only been doing Android for 9 years. I've seen the development tools evolve and improved the past few years. But what do I know. You're probably the expert here.
- usaphp 9y ago
  > But what do I know. You're probably the expert here. Was it really necessary?
  - izacus 9y ago
    I think it's warranted - the OP wrote an insultingly dismissive post with claims which are downright wrong. It would be fine if he only criticised the newbie experience (where he's very right), but he also decided to add a bunch of wrong things in there.
    - s73ver_ 9y ago
      I disagree; I think it made the response be entirely condescending and removed any point they had. For what it's worth, I have about as much experience as they do, and I disagree with them. While the tools have improved, they still have a long way to go.
- pazimzadeh 9y ago
  Maybe that says more about how smart you are than how good the Android ecosystem is.
  - endorphone 9y ago
    And? Without fail, whenever there is a post about Android on HN there'll be someone who miserably regales their tourist experience with Android. But that has zero professional relevance to anyone doing anything with any intention or focus at all. Actually it's worse than zero relevance, and is simply misleading noise. Somehow many of us manage quite fine, and enjoy the experience. In every other realm that sort of drive-by shooting gets rightly criticized. "Tried Rust -- => everywhere. Lame". "Tried vi. Couldn't quit. Garbage."
    - pazimzadeh 9y ago
      Sure, if the only tangible thing that the parent poster said wasn't that he's been on the platform for 9 years. The brain's an amazing thing - it can get used to almost anything, given enough time!
- spurcell93 9y ago
  Congrats on making it 9 years. I've only been doing mobile development for 2 years, and using React Native for most of it. So I have an opinion that may be less biased toward a certain toolset. I'd compare developing on Android very unfavorably to iOS. All the points the OP made are accurate, in my experience. Every time I needed to dive into Android native code, Layout Inflation, etc, I find it to be a crufty and unpleasant system. And gradle is really a pain to use - tons of edge cases and unhelpful error messages. Add to that, you need to support like ten thousand devices, many of which are running Android 4.4 (which, IIRC, is like three years old) and have a WIDE range of screen sizes. Compare that to iOS development, and the differences seem obvious and apparent to me.
  - kllrnohj 9y ago
    > Add to that, you need to support like ten thousand devices, many of which are running Android 4.4 (which, IIRC, is like three years old) and have a WIDE range of screen sizes. I've been developing Android apps for years (before support lib even existed, much less all the fancy new kids) and range of screen sizes has literally never once been an actual issue. Use 'dp' instead of 'px' and you pretty much never have a screen diversity problem. All the platform views & layouts handle the majority of the work. Does React Native make this more complicated for some reason?
    - RivieraKid 9y ago
      Same experience here. The API is the same, so what exactly is the problem? There's an occasional device-specific bug, but I usually don't spend much time on those.
    - shinymark 9y ago
      Device support is a nightmare from a game development perspective if you're coding in C++ and using the GPU directly. Figuring out why the black box shader compiler is crashing on a particular device is not fun.
    - spurcell93 9y ago
      Perhaps screen sizes was a bad example of fragmentation (though, because the range is so much wider than on iOS, keyboard avoiding stuff can be unpleasant). Better examples would be subtle device-specific bugs. Like, off the top of my head, touch handling being handled differently for views on the Galaxy S5, making side swiping impossible. I can't confirm if that's RN specific or not, but I do know that I spent tens of hours on Android specific bugs that just were not present on iOS. And perhaps RN was the culprit for some of these things. But definitely not all.
- sidlls 9y ago
  Android Studio/IntelliJ may be excellent to you, and I'd agree the IDE is better than XCode as far as slinging code into an editor is concerned. However the Android development system isn't just the IDE: it's the build process, integration with debugging tools, and the APIs. Java doesn't have to be a bloated mess of over-engineered cruft. I've seen wonderful, clean Java. Android development is the opposite of that. Kotlin may be great. I haven't used it much, but so far I'm finding it can't hide Android's bloated, over-engineered substructure.
  - izacus 9y ago
    The build process is significantly better in Android world once you actually take a look at how the build process works and need to start doing automated testing and deployment. Xcode tools for actual continious development beyond manual clicking are horrendous and waste a huge amount of people hours.
    - apetrovic 9y ago
      There's third party solution for iOS build automation - https://fastlane.tools https://fastlane.tools. I didn't tried the whole end-to-end solution, but pieces I tried worked very well.
      - izacus 9y ago
        We used that, but sadly it doesn't help with CI, constant simulator / connected device issues and breakages in toolchains when Apple releases new Xcode :(
      - sjellis 9y ago
        Unfortunately, the support for managing code-signing in Fastlane isn't quite fully-baked, and it can get messy. It's still really useful, though, if you have to deal with iOS builds.
- RivieraKid 9y ago
  > There's Instant Run for quick builds. Instant Run was buggy and made builds a lot slower, ironically the last time I tried it. That was after them saying that they fixed a bunch of issues so we should give it another chance. I've been doing Android since 1.0 and started with iOS/Swift half year ago. I think the iOS platform is nicer, simpler, more thought out and overall a better experience, but not by a huge margin. Haven't used Kotlin yet though. One area where iOS sucks is creating and (sometimes) working with UI.
matwood 9y ago
> I just wish they'd work on all the other things that make Android development a horrible experience. Even worse is you're describing the improved Android development experience.
- sidlls 9y ago
  I don't even care for Apple in general. If I were ever to develop these for commercial purposes, however, I'd go Apple all the way and consider Android as a secondary market. This reflects the quality of the development environments and the customer base (in terms of revenue). The only reason I write anything for Android is out of necessity (these are the devices we own).
  - izacus 9y ago
    Funny, because then you'd meet the amateur hour that's Xcode automation and continious integration. As soon as you graduate from a toy app to something you need to maintain for awhile, you find out just in what horrible state the Apple development tools are when it comes to UI testing, building in general and constant breakagaes of code when new iOS is released. We literaly spent a month of man-hours every year to fix up constant breaking Xcode CI setup and iOS API breakages while Android team continued development unimpeded. Not to mention constant breaking changes and crashes of Swift language and IDE toolchain. I do agree that for a complete beginner the experience is significantly better in Apple world, but please do not comment on "commercial purposes" development if you haven't done either.
    - eridius 9y ago
      > and constant breakagaes of code when new iOS is released […] We literaly spent a month of man-hours every year to fix up […] iOS API breakages Unless you're referring to the Swift 2 -> 3 migration process, then I have to seriously question what you're doing that causes so much breakage with iOS version updates. With Obj-C there's usually just a couple of deprecation warnings to handle. With Swift (outside of the 2 -> 3 migration process) there may be a few more updates, due to the Swift SDK wrappers, which may be hard errors instead of merely warnings, but it's still usually pretty easy to fix. And if you are talking about the Swift 2 -> 3 migration, good news, you don't have to do that again! Which makes me wonder, when you say "iOS API breakages", do you really mean you're using SPI, method swizzling, or subview diving and have to deal with the fact that you're doing something against the rules?
i_cant_speel 9y ago
Why is that anytime something comes out from Google (or just about anything, for that matter), people have to find something to complain about? There are more engineers at Google than the ones that were working on this project. Just because they are developing this project doesn't mean they stopped development on all other Android related projects. So why don't we actually discuss the product instead of finding a way to shoehorn in an unrelated topic to complain about?
- sidlls 9y ago
  Android and iOS compete in the same ecosystem. It's extremely relevant, in my opinion, to compare and contrast their offerings. The release of a new product, library, or feature is an excellent time especially because of the freshness and potential additional relevance. And I was talking about the product. ARcore is a single example of the larger, broader problems I "complained" about.
- kbenson 9y ago
  The problem isn't that someone mentions something else, the problem (from the standpoint of discussion of this story) is that comments like this resonate enough with people to get upvotes. That's actually Google's problem. Even if you think it resonates because people are just drinking the Apple kool-aid, that's still Google's problem. Let Google handle its own problems, and use whatever vote power you have to help steer the conversation here. Complaining about it doesn't exactly reduce the signal to noise ratio.
- frahs 9y ago
  This is the view from the inside as a Google employee. You see all these lines between what you work on and what other people work on. From the outside? People see it quite differently. For an example you can maybe relate to, it's easy to criticize Apple for recent design decisions (touchbar, lack of escape button, etc) and say that the whole company is losing touch with reality. The people working on the iphone might feel the same way you do here: There are more engineers at Apple than the ones working on the touchbar.
chris2112 9y ago
>It's nice to see them finally providing something similar to ARKit ARKit isn't even out yet though...
- iainmerrick 9y ago
  You can download the Xcode and iOS betas and try it out right now, on current hardware. And you can trust that all your potential users will have it by the end of the year.
  - MBCook 9y ago
    Further more based on the Apple event being on the 12th as expected it will be in production in under a month.
c0mpute 9y ago
On the other hand - I find its the other way. Xcode is the most "diff" IDE from other IDEs. I like Swift but just dont like Objective-C. The build tools and ecosystem is too tightly tied (I like to switch between development machines without having to always be on a mac). Java is definitely painful, but I suppose the bias I have here is that I have developed on it for several years. The breath of fresh air so far has been React-native and i wish more things get ported over to JS (or like Expo kit).
- fish_fan 9y ago
  Xcode is best for things like managing certs, not actually working in. The intellij version is pretty good; it integrates well with the build system and debugger. I find it curious you bring up Expo as i've found that is the most opaque and user unfriendly IDE i've used in some time; i don't get why they don't just leverage VSCode and quality tooling over Yet Another Goddamn IDE.
  - saagarjha 9y ago
    Curiously, I feel the opposite way–Xcode's support for managing certificates is pretty awful (it's gotten better recently, but it still occasionally gives cryptic errors for no discernible reason). For actual programming, though, it works pretty well as long as it doesn't crash.
  - marksomnian 9y ago
    If you mean XDE, it's not meant to replace VSCode or Sublime or anything. XDE just gives you buttons for common actions that you would normally do via the CLI.
  - c0mpute 9y ago
    To clarify - Expo as a framework, and not XDE. I think they have made Expo eject a bit cumbersome but works with some wrangling. I like the the Expokit framework in general but don't want to be tied to the Expo's release chain.
- AJRF 9y ago
  "i wish more things get ported over to JS" Please, please don't say this out loud. It might come true.
lucideer 9y ago
I'd mostly agree, but the one massive pain point I have with Apple (iOS) development is automatability. You seem to need manual steps in the XCode GUI for everything, or at least if you don't, it's not well documented or generally known by the community how to set things up without manual UI steps. Android's mess of Java cruft may be overkill, but it's at least well-documented text-file-configurable and can 100% be maintained without ever installing Studio.
- kobeya 9y ago
  Which steps? I don't do much mobile development, but I have done some, and I have never used the XCode GUI, ever.
prophesi 9y ago
Eh, they've both got their pros and cons. iOS: + Swift + Less screen sizes to worry about + Less iOS versions to worry about + XCode is much lighter on resources - Mac only - XCode might crash every now and then - Probably need an iOS device, as the simulator is very slow - $100/yr developer fee Android: + Kotlin + Studio runs everywhere + No developer fee + More stable IDE + Decent emulation - Countless screen sizes to worry about - Lots of Android versions to worry about - $25 developer account fee - Android Studio is resource heavy - NDK requires lots of JNI boilerplate Though, with all of this AR stuff, I'd just go the Unity/Unreal route, as it will probably be very game-y and such.
- eridius 9y ago
  > - Probably need an iOS device, as the emulator is very slow Only if you're doing OpenGL, as that's actually rendered in software (not sure about if you're using Metal). Otherwise, the simulator (not emulator!) is fast, which is as it should be as it's running native code (which is why it's a simulator, not an emulator). If anything, it's important to test on devices because the simulator can mask performance problems (though as devices become more and more powerful that becomes less of an issue).
  - kobeya 9y ago
    I'm sure you're correct, but that seems backwards. OpenGL is a cross platform API, why would that be emulated in software? And the iOS devices have a different CPU architecture (ARM) than the MacBook Pro (x64) you develop on, so how is that being run as native code?
    - eric_h 9y ago
      When you compile for the simulator, the binary output is x64.
    - eridius 9y ago
      I can only speculate as to why OpenGL is rendered in software, I assume it has to do with the fact that the graphics capabilities are different on iOS versus Macs, and perhaps software rendering is needed to ensure consistent behavior or implementation of OpenGL extensions (though I'm not positive that the simulator offers the same OpenGL extensions anyway; I'm not a graphics programmer so I haven't really explored this). As for it being a simulator, it's because your app actually compiles to x86_64 code when you're targeting the simulator. When you switch between targeting the simulator and targeting a device, your app is recompiled for the new architecture. And the simulator includes a complete copy of iOS and all its frameworks (but without most of the built-in apps) that were compiled for x86_64 in order to run in the simulator.
RivieraKid 9y ago
Having developed for Android for many years and for iOS/Swift for over half a year, here's a bunch of random thoughts: Developing for iOS/Swift is a more pleasant experience, the APIs are simpler and more well-thought. But it's not a huge difference. Android Studio is a better (but uglier) IDE, but not by as much as people say. Android's Activity and Fragment APIs is a horrible joke. I mean, Google is supposed to have these super smart devs, how could they design this mess? Creating UI in iOS sucks. Specifically, Auto Layout and Interface Builder. I usually use Fb's Yoga, it's not ideal, but less of a pain. Swift is one of the best-designed languages out there.
- ehsankia 9y ago
  There's a lot of complaints about Java being verbose and bad, does Kotlin fix these issues? Does it make it fun again? I personally used to dislike programming until I started using Python at work, and I fell in love again. Syntax, libraries and API design can definitely have a huge impact on how you enjoy what you do. As for your comment about Activity/Fragments, they've had a few I/O talks going over their thoughts: https://www.youtube.com/watch?v=k3IT-IJ0J98 https://www.youtube.com/watch?v=k3IT-IJ0J98 https://www.youtube.com/watch?v=FrteWKKVyzI https://www.youtube.com/watch?v=FrteWKKVyzI
  - RivieraKid 9y ago
    I don't think Java 8 is that bad, it's just mediocre. It's fast and has a good ecosystem. Yeah, Python is fun, it seems effortless to do stuff there compared to Java. For example, "a = [1]" vs "List<Integer> a = new ArrayList<>(); a.add(1)" - and then you have to compile and run, no REPL to try it out. Recently I've been using Julia, it's maybe the most fun I had with a language. Some things are much easier to do than in Python - and it's 1 to 2 orders of magnitude faster.
    - vosper 9y ago
      Since you mentioned Julia - are you using it for math or math-related programming, or doing something else? It looks interesting to me, but I'm a web dev (Python on the backend) and don't have much use for most of the math stuff, so I don't know if it's suitable.
deleted 9y ago
[deleted]
krolley 9y ago
Out of curiosity, what apps did you build for your wife or kids? To solve what problems?

by sidlls 9y ago

dannyr 9y ago

Android Studio/IntelliJ is an excellent IDE. Kotlin is a great language. There's Instant Run for quick builds. I've only been doing Android for 9 years. I've seen the development tools evolve and improved the past few years. But what do I know. You're probably the expert here.

usaphp 9y ago
> But what do I know. You're probably the expert here. Was it really necessary?
- izacus 9y ago
  I think it's warranted - the OP wrote an insultingly dismissive post with claims which are downright wrong. It would be fine if he only criticised the newbie experience (where he's very right), but he also decided to add a bunch of wrong things in there.
  - s73ver_ 9y ago
    I disagree; I think it made the response be entirely condescending and removed any point they had. For what it's worth, I have about as much experience as they do, and I disagree with them. While the tools have improved, they still have a long way to go.
pazimzadeh 9y ago
Maybe that says more about how smart you are than how good the Android ecosystem is.
- endorphone 9y ago
  And? Without fail, whenever there is a post about Android on HN there'll be someone who miserably regales their tourist experience with Android. But that has zero professional relevance to anyone doing anything with any intention or focus at all. Actually it's worse than zero relevance, and is simply misleading noise. Somehow many of us manage quite fine, and enjoy the experience. In every other realm that sort of drive-by shooting gets rightly criticized. "Tried Rust -- => everywhere. Lame". "Tried vi. Couldn't quit. Garbage."
  - pazimzadeh 9y ago
    Sure, if the only tangible thing that the parent poster said wasn't that he's been on the platform for 9 years. The brain's an amazing thing - it can get used to almost anything, given enough time!
spurcell93 9y ago
Congrats on making it 9 years. I've only been doing mobile development for 2 years, and using React Native for most of it. So I have an opinion that may be less biased toward a certain toolset. I'd compare developing on Android very unfavorably to iOS. All the points the OP made are accurate, in my experience. Every time I needed to dive into Android native code, Layout Inflation, etc, I find it to be a crufty and unpleasant system. And gradle is really a pain to use - tons of edge cases and unhelpful error messages. Add to that, you need to support like ten thousand devices, many of which are running Android 4.4 (which, IIRC, is like three years old) and have a WIDE range of screen sizes. Compare that to iOS development, and the differences seem obvious and apparent to me.
- kllrnohj 9y ago
  > Add to that, you need to support like ten thousand devices, many of which are running Android 4.4 (which, IIRC, is like three years old) and have a WIDE range of screen sizes. I've been developing Android apps for years (before support lib even existed, much less all the fancy new kids) and range of screen sizes has literally never once been an actual issue. Use 'dp' instead of 'px' and you pretty much never have a screen diversity problem. All the platform views & layouts handle the majority of the work. Does React Native make this more complicated for some reason?
  - RivieraKid 9y ago
    Same experience here. The API is the same, so what exactly is the problem? There's an occasional device-specific bug, but I usually don't spend much time on those.
  - shinymark 9y ago
    Device support is a nightmare from a game development perspective if you're coding in C++ and using the GPU directly. Figuring out why the black box shader compiler is crashing on a particular device is not fun.
  - spurcell93 9y ago
    Perhaps screen sizes was a bad example of fragmentation (though, because the range is so much wider than on iOS, keyboard avoiding stuff can be unpleasant). Better examples would be subtle device-specific bugs. Like, off the top of my head, touch handling being handled differently for views on the Galaxy S5, making side swiping impossible. I can't confirm if that's RN specific or not, but I do know that I spent tens of hours on Android specific bugs that just were not present on iOS. And perhaps RN was the culprit for some of these things. But definitely not all.
sidlls 9y ago
Android Studio/IntelliJ may be excellent to you, and I'd agree the IDE is better than XCode as far as slinging code into an editor is concerned. However the Android development system isn't just the IDE: it's the build process, integration with debugging tools, and the APIs. Java doesn't have to be a bloated mess of over-engineered cruft. I've seen wonderful, clean Java. Android development is the opposite of that. Kotlin may be great. I haven't used it much, but so far I'm finding it can't hide Android's bloated, over-engineered substructure.
- izacus 9y ago
  The build process is significantly better in Android world once you actually take a look at how the build process works and need to start doing automated testing and deployment. Xcode tools for actual continious development beyond manual clicking are horrendous and waste a huge amount of people hours.
  - apetrovic 9y ago
    There's third party solution for iOS build automation - https://fastlane.tools https://fastlane.tools. I didn't tried the whole end-to-end solution, but pieces I tried worked very well.
    - izacus 9y ago
      We used that, but sadly it doesn't help with CI, constant simulator / connected device issues and breakages in toolchains when Apple releases new Xcode :(
    - sjellis 9y ago
      Unfortunately, the support for managing code-signing in Fastlane isn't quite fully-baked, and it can get messy. It's still really useful, though, if you have to deal with iOS builds.
RivieraKid 9y ago
> There's Instant Run for quick builds. Instant Run was buggy and made builds a lot slower, ironically the last time I tried it. That was after them saying that they fixed a bunch of issues so we should give it another chance. I've been doing Android since 1.0 and started with iOS/Swift half year ago. I think the iOS platform is nicer, simpler, more thought out and overall a better experience, but not by a huge margin. Haven't used Kotlin yet though. One area where iOS sucks is creating and (sometimes) working with UI.

matwood 9y ago

> I just wish they'd work on all the other things that make Android development a horrible experience. Even worse is you're describing the improved Android development experience.

sidlls 9y ago
I don't even care for Apple in general. If I were ever to develop these for commercial purposes, however, I'd go Apple all the way and consider Android as a secondary market. This reflects the quality of the development environments and the customer base (in terms of revenue). The only reason I write anything for Android is out of necessity (these are the devices we own).
- izacus 9y ago
  Funny, because then you'd meet the amateur hour that's Xcode automation and continious integration. As soon as you graduate from a toy app to something you need to maintain for awhile, you find out just in what horrible state the Apple development tools are when it comes to UI testing, building in general and constant breakagaes of code when new iOS is released. We literaly spent a month of man-hours every year to fix up constant breaking Xcode CI setup and iOS API breakages while Android team continued development unimpeded. Not to mention constant breaking changes and crashes of Swift language and IDE toolchain. I do agree that for a complete beginner the experience is significantly better in Apple world, but please do not comment on "commercial purposes" development if you haven't done either.
  - eridius 9y ago
    > and constant breakagaes of code when new iOS is released […] We literaly spent a month of man-hours every year to fix up […] iOS API breakages Unless you're referring to the Swift 2 -> 3 migration process, then I have to seriously question what you're doing that causes so much breakage with iOS version updates. With Obj-C there's usually just a couple of deprecation warnings to handle. With Swift (outside of the 2 -> 3 migration process) there may be a few more updates, due to the Swift SDK wrappers, which may be hard errors instead of merely warnings, but it's still usually pretty easy to fix. And if you are talking about the Swift 2 -> 3 migration, good news, you don't have to do that again! Which makes me wonder, when you say "iOS API breakages", do you really mean you're using SPI, method swizzling, or subview diving and have to deal with the fact that you're doing something against the rules?

i_cant_speel 9y ago

Why is that anytime something comes out from Google (or just about anything, for that matter), people have to find something to complain about? There are more engineers at Google than the ones that were working on this project. Just because they are developing this project doesn't mean they stopped development on all other Android related projects. So why don't we actually discuss the product instead of finding a way to shoehorn in an unrelated topic to complain about?

sidlls 9y ago
Android and iOS compete in the same ecosystem. It's extremely relevant, in my opinion, to compare and contrast their offerings. The release of a new product, library, or feature is an excellent time especially because of the freshness and potential additional relevance. And I was talking about the product. ARcore is a single example of the larger, broader problems I "complained" about.
kbenson 9y ago
The problem isn't that someone mentions something else, the problem (from the standpoint of discussion of this story) is that comments like this resonate enough with people to get upvotes. That's actually Google's problem. Even if you think it resonates because people are just drinking the Apple kool-aid, that's still Google's problem. Let Google handle its own problems, and use whatever vote power you have to help steer the conversation here. Complaining about it doesn't exactly reduce the signal to noise ratio.
frahs 9y ago
This is the view from the inside as a Google employee. You see all these lines between what you work on and what other people work on. From the outside? People see it quite differently. For an example you can maybe relate to, it's easy to criticize Apple for recent design decisions (touchbar, lack of escape button, etc) and say that the whole company is losing touch with reality. The people working on the iphone might feel the same way you do here: There are more engineers at Apple than the ones working on the touchbar.

chris2112 9y ago

>It's nice to see them finally providing something similar to ARKit ARKit isn't even out yet though...

iainmerrick 9y ago
You can download the Xcode and iOS betas and try it out right now, on current hardware. And you can trust that all your potential users will have it by the end of the year.
- MBCook 9y ago
  Further more based on the Apple event being on the 12th as expected it will be in production in under a month.

c0mpute 9y ago

On the other hand - I find its the other way. Xcode is the most "diff" IDE from other IDEs. I like Swift but just dont like Objective-C. The build tools and ecosystem is too tightly tied (I like to switch between development machines without having to always be on a mac). Java is definitely painful, but I suppose the bias I have here is that I have developed on it for several years. The breath of fresh air so far has been React-native and i wish more things get ported over to JS (or like Expo kit).

fish_fan 9y ago
Xcode is best for things like managing certs, not actually working in. The intellij version is pretty good; it integrates well with the build system and debugger. I find it curious you bring up Expo as i've found that is the most opaque and user unfriendly IDE i've used in some time; i don't get why they don't just leverage VSCode and quality tooling over Yet Another Goddamn IDE.
- saagarjha 9y ago
  Curiously, I feel the opposite way–Xcode's support for managing certificates is pretty awful (it's gotten better recently, but it still occasionally gives cryptic errors for no discernible reason). For actual programming, though, it works pretty well as long as it doesn't crash.
- marksomnian 9y ago
  If you mean XDE, it's not meant to replace VSCode or Sublime or anything. XDE just gives you buttons for common actions that you would normally do via the CLI.
- c0mpute 9y ago
  To clarify - Expo as a framework, and not XDE. I think they have made Expo eject a bit cumbersome but works with some wrangling. I like the the Expokit framework in general but don't want to be tied to the Expo's release chain.
AJRF 9y ago
"i wish more things get ported over to JS" Please, please don't say this out loud. It might come true.

lucideer 9y ago

I'd mostly agree, but the one massive pain point I have with Apple (iOS) development is automatability. You seem to need manual steps in the XCode GUI for everything, or at least if you don't, it's not well documented or generally known by the community how to set things up without manual UI steps. Android's mess of Java cruft may be overkill, but it's at least well-documented text-file-configurable and can 100% be maintained without ever installing Studio.

kobeya 9y ago
Which steps? I don't do much mobile development, but I have done some, and I have never used the XCode GUI, ever.

prophesi 9y ago

Eh, they've both got their pros and cons. iOS: + Swift + Less screen sizes to worry about + Less iOS versions to worry about + XCode is much lighter on resources - Mac only - XCode might crash every now and then - Probably need an iOS device, as the simulator is very slow - $100/yr developer fee Android: + Kotlin + Studio runs everywhere + No developer fee + More stable IDE + Decent emulation - Countless screen sizes to worry about - Lots of Android versions to worry about - $25 developer account fee - Android Studio is resource heavy - NDK requires lots of JNI boilerplate Though, with all of this AR stuff, I'd just go the Unity/Unreal route, as it will probably be very game-y and such.

eridius 9y ago
> - Probably need an iOS device, as the emulator is very slow Only if you're doing OpenGL, as that's actually rendered in software (not sure about if you're using Metal). Otherwise, the simulator (not emulator!) is fast, which is as it should be as it's running native code (which is why it's a simulator, not an emulator). If anything, it's important to test on devices because the simulator can mask performance problems (though as devices become more and more powerful that becomes less of an issue).
- kobeya 9y ago
  I'm sure you're correct, but that seems backwards. OpenGL is a cross platform API, why would that be emulated in software? And the iOS devices have a different CPU architecture (ARM) than the MacBook Pro (x64) you develop on, so how is that being run as native code?
  - eric_h 9y ago
    When you compile for the simulator, the binary output is x64.
  - eridius 9y ago
    I can only speculate as to why OpenGL is rendered in software, I assume it has to do with the fact that the graphics capabilities are different on iOS versus Macs, and perhaps software rendering is needed to ensure consistent behavior or implementation of OpenGL extensions (though I'm not positive that the simulator offers the same OpenGL extensions anyway; I'm not a graphics programmer so I haven't really explored this). As for it being a simulator, it's because your app actually compiles to x86_64 code when you're targeting the simulator. When you switch between targeting the simulator and targeting a device, your app is recompiled for the new architecture. And the simulator includes a complete copy of iOS and all its frameworks (but without most of the built-in apps) that were compiled for x86_64 in order to run in the simulator.

RivieraKid 9y ago

Having developed for Android for many years and for iOS/Swift for over half a year, here's a bunch of random thoughts: Developing for iOS/Swift is a more pleasant experience, the APIs are simpler and more well-thought. But it's not a huge difference. Android Studio is a better (but uglier) IDE, but not by as much as people say. Android's Activity and Fragment APIs is a horrible joke. I mean, Google is supposed to have these super smart devs, how could they design this mess? Creating UI in iOS sucks. Specifically, Auto Layout and Interface Builder. I usually use Fb's Yoga, it's not ideal, but less of a pain. Swift is one of the best-designed languages out there.

ehsankia 9y ago
There's a lot of complaints about Java being verbose and bad, does Kotlin fix these issues? Does it make it fun again? I personally used to dislike programming until I started using Python at work, and I fell in love again. Syntax, libraries and API design can definitely have a huge impact on how you enjoy what you do. As for your comment about Activity/Fragments, they've had a few I/O talks going over their thoughts: https://www.youtube.com/watch?v=k3IT-IJ0J98 https://www.youtube.com/watch?v=k3IT-IJ0J98 https://www.youtube.com/watch?v=FrteWKKVyzI https://www.youtube.com/watch?v=FrteWKKVyzI
- RivieraKid 9y ago
  I don't think Java 8 is that bad, it's just mediocre. It's fast and has a good ecosystem. Yeah, Python is fun, it seems effortless to do stuff there compared to Java. For example, "a = [1]" vs "List<Integer> a = new ArrayList<>(); a.add(1)" - and then you have to compile and run, no REPL to try it out. Recently I've been using Julia, it's maybe the most fun I had with a language. Some things are much easier to do than in Python - and it's 1 to 2 orders of magnitude faster.
  - vosper 9y ago
    Since you mentioned Julia - are you using it for math or math-related programming, or doing something else? It looks interesting to me, but I'm a web dev (Python on the backend) and don't have much use for most of the math stuff, so I don't know if it's suitable.

deleted 9y ago

[deleted]

krolley 9y ago

Out of curiosity, what apps did you build for your wife or kids? To solve what problems?