[HN Gopher] Apple's closed-source approach is losing out to AI a...
___________________________________________________________________
Apple's closed-source approach is losing out to AI app builders
Author : trevor-e
Score : 61 points
Date : 2025-02-19 20:41 UTC (2 hours ago)
(HTM) web link (www.telkins.dev)
(TXT) w3m dump (www.telkins.dev)
| jopsen wrote:
| Is gen ai app development really that important?
|
| Does it make real apps? Or only prototypes and trash?
|
| Do we need quantity or quality apps?
| baxtr wrote:
| It seems to me that ai apps are great for prototyping and
| getting to v0. Maintenance and continuous improvement seem to
| be more challenging.
| throwaway48476 wrote:
| I recently saw a niche industry specific chatgpt wrapper. I
| don't think anyone is actually building anything of value with
| gen AI.
| resource_waste wrote:
| I did. I do.
|
| I don't use it for everything, but it is a 2x-10x multiplier.
| throwaway0123_5 wrote:
| This is a pretty big range. Are you saying the overall
| multiplier for all of your work is somewhere between 2 and
| 10x, or that some tasks are 2x and others are 10x?
| dingnuts wrote:
| relevant username
| layman51 wrote:
| This is a good point and it reminds me of a link to an news
| article someone had shared some weeks earlier about how AI-
| generated literature in the form of ebooks is already flooding
| public libraries that subscribe to certain lending platforms.
| In a sense, it could be an advantage to have systems where it
| is so cumbersome to get LLMs to help you with generation so
| that people have to put at least a little bit of effort.
| dzikimarian wrote:
| It saves a lot of time. You don't need it to generate whole app
| - just do some tedious bits.
|
| It's basically electric screwdriver. You can open & close your
| laptop with old piece of iron. It even won't be worse in terms
| of quality, but if you want to fix 20 of them in a day it
| doesn't make sense.
| kmeisthax wrote:
| It's not.
|
| _However_ , the fact that integrating these tools with any
| sort of Apple toolchain is a nightmare is still a problem.
| Because even if you don't care about AI slop coding, there's
| plenty of other things that developers are used to that become
| far more difficult when the only option[0] is proprietary dev
| tools with very strict hardware licensing requirements attached
| to it. This puts a very real cost on iOS development.
|
| The only reason why developers put up with iOS _now_ is because
| it has half the US mobile market, so brown-nosing Apple is
| mandatory for certain app classes. This doesn 't make the cost
| go away, it just means it gets spread around[1], like how
| everyone has to pay credit card fees or mobile storefront fees
| even when they're paying with cash or buying straight from the
| developer. But when that market power isn't there, such as on
| macOS[2] or visionOS (lol), developers just straight-up don't
| bother supporting the platform because Apple is disrespectful
| to developers.
|
| [0] I am aware of that one non-Apple iOS toolchain, it still
| requires you grab the SDK files yourself off a Real Mac(tm)
| which is a pain in the ass and not going to pass a corporate
| compliance department's muster.
|
| [1] The exact mechanism that forces cost-sharing is called a
| most favored nation agreement. You are required to offer the
| best pricing to people paying your junk fee and cannot discount
| around the fee.
|
| [2] People often blame Metal for macOS gaming being terrible.
| This is missing the point. iOS has the same core technology
| requirement; so all the middleware _has_ to support Metal
| _anyway_. But if you don 't need to be on mobile, you don't
| need to support _any_ Apple platforms, which is preferable.
| dale_glass wrote:
| I find it reasonably useful given these conditions:
|
| 1. I know what I want.
|
| 2. I don't know off the top of my head how to accomplish it.
|
| 3. However, I do know enough to tell whether what the AI
| generated works right.
|
| So for me it covers cases like "I know databases and I know
| programming, but I don't know enough Python to do a DB query
| without looking for docs. Have Copilot generate some working
| sample code, and then I can pick things up from there".
|
| I'm sure bigger things can be done but I think just that alone
| is extremely useful. Saves a bunch of time on googling, making
| it past all the ads, the requests to subscribe, the far too
| long introductions, etc. Sometimes all I want is 20 lines of
| sample code and nothing else, and AI seems to do very well at
| that without leaving the IDE.
| BriggyDwiggs42 wrote:
| I'm really not looking forward to the day when they start
| serving ads through LLMs. Hopefully local is solid enough by
| then to do most of the same stuff.
| mandevil wrote:
| Give OpenAI 25 years and they're going to be throwing up
| plenty of ads in our faces. Source: I remember using Google
| in 1999.
|
| Momento mori to anything raising tens of billions of dollars
| from VCs and PE's. The UX is going to get much worse,
| surprisingly quickly.
| pram wrote:
| "The platforms thriving right now are all built on open source
| software. More and more teams are building apps in React Native
| rather than Swift"
|
| Isn't Swift literally open source software lol
| etchalon wrote:
| Bad journalism is hilarious.
| FloorEgg wrote:
| If you noticed inaccuracies in the article you might be
| interested to know that the article was written by AI.
|
| And for those of you hissing at my previous comment you might
| be interested to know that this joke was written by AI.
|
| Now you don't know what to do.
|
| Rip Norm Macdonald
| saagarjha wrote:
| I mean I could downvote it
| cess11 wrote:
| I think they mean SwiftUI.
| sampton wrote:
| No self respecting iOS developer would pick React Native over
| SwiftUI.
| echelon wrote:
| Why would a company hire iOS developers when they can build
| everything for all platforms in a single language and
| framework? It's fungible, interchangeable, easy to maintain,
| and easy to hire for.
|
| Apple is being boneheaded by going their own way. But closed
| systems lorded over by tyrannical giants typically are.
| saagarjha wrote:
| Because the single language and framework makes worse apps
| echelon wrote:
| Only because Apple made a non-open platform.
| gbear605 wrote:
| React Native makes worse apps for Android too
| resource_waste wrote:
| There does seem to be a bit of cult-like loyalty to every
| decision Apple makes.
|
| I would agree with your statement. However...
|
| No self respecting developer would pick SwiftUI over React
| Native.
|
| But that is too generic of a statement to stand by. I just
| personally have prioritized development time over... uh..
| fandom?
| felizuno wrote:
| I'm a self respecting developer who has been using React in
| production for almost 10 years now, and SiwftUI is
| significantly better than RN. I wasn't a huge fan of
| learning to deal with XCode, but yeah it's not fandom it
| just actually works better with fewer quirks and downstream
| perf issues.
| kmeisthax wrote:
| Swift, the core language, has a FOSS compiler. SwiftUI is a
| proprietary UI toolkit library and app framework whose only
| relation to Swift is that it's written in it. It would be like
| calling GDK "ValaUI" or Bevy "RustEngine".
| echelon wrote:
| Swift has no use beyond writing software to target Apple
| users.
|
| Apple isn't viewed as friendly to open source since you can't
| even distribute software to their platform without going
| through their censorship/taxation centralized review process.
| (And an army of people will rush to tell you this is okay.)
|
| The meme of Swift being useful to anything but Apple devs
| needs to die.
| trevor-e wrote:
| Swift is open source, but SwiftUI and UIKit are both closed-
| source which is what I meant.
| saurik wrote:
| > From there, compiling code for iOS is notoriously difficult and
| not officially supported outside of using Xcode.
|
| I mean, this is a stretch... you really have to go out of your
| way to narrowly define "officially supported" to the point of
| absurdity: Apple _clearly_ supports compiling for iOS outside of
| Xcode, as Xcode doesn 't even do the compilation, never has, and
| --we can be pretty confident in saying-- _never will_. Meanwhile,
| despite many people using automatic provisioning, Apple 's portal
| let's you do it all manually: it isn't as if there are a bunch of
| missing pieces if you aren't using Xcode to do your build. Very
| large companies routinely deploy code for the most popular
| applications without using Xcode and smaller projects are often
| built in languages or frameworks using tooling that completely
| bypasses Xcode... if you don't think Xcode is a win (and it
| isn't: there is a good reason why the really large-scale projects
| don't use it) _just don 't use it_ and your life will get better.
| And, if working in AI is really the competitive advantage people
| claim, it would seem like a no-brainer to finally get around to
| porting your project build to escape Xcode.
| rgovostes wrote:
| > For example, there is an xcodebuild command you can run, but
| it often doesn't work with table stakes features like
| incremental builds
|
| I don't think this is true, either.
| trevor-e wrote:
| I could have worded this better since running xcodebuild is
| obviously outside of Xcode. But it's not a stretch.
|
| Is it possible? Yes, of course. Bazel and Buck iOS builds have
| existed for a long time, and many large teams use them. You can
| even use Gradle to build an iOS project.
|
| Does Apple officially support any of those? No, you won't find
| any Apple instructions telling you how to do any of this, Apple
| expects iOS apps submitted to the store to be built with Xcode.
| You're on your own with these solutions. And setting up Bazel
| for an iOS project is not an easy undertaking.
| mirkodrummer wrote:
| If you take a look around x, reddit or linkedin nowadays it seems
| full of non tech people or parents proud of their children making
| "complete functioning apps" without any coding. Usually they're
| nothing more than specialized todo lists or calendaring apps for
| keeping track of some habits. Do we really need all those apps?
| I'm worried that if I have a good idea and it happens I can
| execute it well, then the app would be buried in the millions of
| "v0" apps out there. And no, Apple won't review them all, it's
| impossible... maybe an AI will lol
| saagarjha wrote:
| Despite not really liking AI-generated content very much myself
| I think it is quite neat that everyone can now have small apps
| that precisely cater to their needs.
| mirkodrummer wrote:
| What they need? More todo apps? Or simple crud apps that they
| could have hacked together with no code tools for years? If
| so it speaks long dinstances about the current state of
| software
| munchler wrote:
| This is exactly how I felt as a photographer when smart phones
| took over the world 15 years ago. I try to remind myself that
| democratization is good, even if it isn't necessarily pretty.
| robenkleene wrote:
| > According to Evan Bacon, one of the developers leading the Expo
| project, 40 of the top 100 iOS apps are now non-native. And with
| the proliferation of AI app builders, the future is starting to
| look even more non-native.
|
| The linked tweet
| (https://x.com/Baconbrix/status/1888633966938276267) is only
| about _shopping_ apps.
| trevor-e wrote:
| Good catch, totally missed that, will update
| s_dev wrote:
| Why does Apple allow Expo apps on the App Store when they
| effectively bypass App Review? Doesn't this go against their
| own policies?
|
| I say that as someone who uses Expo precisely for this reason.
| trevor-e wrote:
| It's definitely a very gray area within Apple's policy.
| Shorebird (Flutter OTA updates) describes it best in their
| FAQ (https://docs.shorebird.dev/faq/#does-shorebird-comply-
| with-a...).
|
| It seems to be as long as you don't significantly alter the
| primary purpose of the app, then it's "allowed". But that's a
| very broad interpretation and puts native Swift apps at a
| huge disadvantage.
| gleenn wrote:
| I think there is an implicit assumption that the top 40 apps is
| reflective of what all app developers should be doing. The top
| 40 apps are probably also all made my mega corps with enormous
| budgets and desires to be multi-platform right out of the gate,
| and also have already vetted necessary issues like "does app
| performance matter" versus "does developer productivity and
| app-parity across platforms" matter. Just because a top 40 app
| is high, maybe it's something like Amazon's shopping app, maybe
| the trade-offs are heavily towards slow-starting but very
| feature rich and also equivalent across platforms is necessary.
| If someone writes a note-taking app that takes 10 seconds to
| start because it's loading some JavaScript updates and spinning
| up the non-native code execution hamsters, I already forgot my
| note. Native is obviously desirable. Or a game is interesting
| because maybe people are patient for a slow load, but still
| desire very fast native performance. My main point is there are
| quite a few trade-offs, and it's unsurprising the leads at Expo
| are saying look how awesome this stack is. I've used Expo and
| it was awesome, but it comes with costs too.
| ToucanLoucan wrote:
| From a strictly UX perspective, I'm strongly of the opinion
| that most shopping apps also _suck industrial quantities of
| ass._
|
| Like I use them, I can't not and it beats ordering stuff over
| the phone or whatever. But most of them at best can rise to the
| dizzying heights of "tolerable."
| resource_waste wrote:
| Wow this is interesting AF actually.
|
| I also imagine that Linux is going to have quite the edge over
| microsoft on AI based programs.
| drowntoge wrote:
| AI assistance in IDEs was the final nail in the coffin for
| Apple's development environment, which had already --and
| consistently-- been lagging behind for over a decade.
| rgovostes wrote:
| The author's opening complaint is that the AI coding assistant
| features in Xcode aren't state of the art.
|
| Note: Xcode does have predictive code completion models and Swift
| Assist. GitHub Copilot for Xcode is an open source extension,
| proving that it is possible to extend Xcode with newer
| capabilities.
|
| The author cites examples of superior AI app builders that can
| generate non-native mobile apps, and claims that this will lead
| to growth in non-native iOS apps because native development is
| not keeping up.
|
| The author argues that the lack of AI _native_ app builders is
| because Xcode is closed source and iOS development is too heavily
| tied to Xcode. Counterargument: Doesn 't the existence of all
| these non-native iOS apps the author cites suggest that this
| isn't really true?
|
| The argument takes shift toward imagining a web-based third-party
| tool for app development and then describing the obstacles to
| this, like having to run the iOS simulator in virtual machines on
| Apple hardware. Where is the argument for why these hypothetical
| AI app builder tools have to be cloud-based, SaaS, web apps? This
| is at odds with the author's earlier stated preference for native
| apps. The idea of cross-compiling SwiftUI to WASM to run in the
| browser is the exact kind of thing that makes non-native apps
| buggy and unpleasant to use.
___________________________________________________________________
(page generated 2025-02-19 23:00 UTC)