Very interesting, but I can't help but wonder: are developers really interested in working on an iPad? I feel like this is exactly the kind of job where a laptop is more efficient, for a couple reasons: 1/ Physical keyboard 2/ Over extended periods of time, even though more intuitive, touchscreen feels more exhausting to use than touchpad because you can't easily rest your hands.
And if the targeted usage is "iPad with a keyboard on a desk" well, at this point it's mostly a laptop anyway so as a developer why even bother getting a tablet in the first place?
> this is exactly the kind of job where a laptop is more efficient
You are correct, but I think efforts like this are an important part of discovering how we can make the tablet form factor useful for more types of productivity. Software design is an evolutionary process, and I think professional tablet software is still pretty stunted in that department. Largely down to Apple's endless resistance against allowing the iPad to be used as a computer rather than a media appliance.
The more stuff we get like this, the sooner we can collectively work out how to work around the shortcomings (no guaranteed keyboard, poor feature discoverability of touch-first UIs) and lean into the positives (handheld, ultraportable, direct manipulation).
It's crazy that we've had the iPad for 14 years and tablet computers in general much longer than that but we seemingly still haven't worked it out yet. It still feels like the only options are scaled up phone software (iOS, Android) or desktop software with a touch layer awkwardly bolted on (Windows).
>> It's crazy that we've had the iPad for 14 years and tablet computers in general much longer than that but we seemingly still haven't worked it out yet.
Maybe there's nothing to work out? At least for activities like this
People for years buy add on tablets as a peripheral for many types of graphics work, so the device is already a global maximum for certain types of work. No and low code solutions aside, anytime you’re bringing a keyboard in the mix the tablet has already lost.
There may not be, but unless it is attempted seriously do we actually know? Is the current local maxima near the global one or are we a long ways off? I have no idea, but I can't assume we are already there just because my imagination can't come up with a better solution.
For me getting the task done - produce something valuable - would be more important than trying to validate the usefuleness of some hardware for some edge case that seen unimportant by the vendor (and probably for enough of reasons, considering the inherent and listed above limitations not too vendor specific). When there is a suitable device for that use already, for long.
1. By porting the frontend to SwiftUi, they’re actually making it more native for all Apple platforms. He hints at it, but this is a great first step to having Godot native on visionOS where they can iterate on their games natively in device.
2. A lot of creators (not necessarily developers) have switched to the iPad as a primary creation device. Perhaps not a majority by any means, but a sizeable amount.
Concept artists are on iPad. Recently the character designer for Blue Eye Samurai did most of their work in Procreate.
3D sculptors are picking it up as well with Nomad sculpt and I think the soon to be released ZBrush for iPad (September 10th apparently).
So if you’re on the more visual side of things, and you’ve already got your workflow on iPad, this lets you continue that workflow.
That's a shame. Having a "project" is what kicks off learning the cool bits about computers. If you can't do it with the devices we're giving kids, we are robbing our future inventors.
I’ve noticed most of the people we hire these days for dev roles have no idea how computers or operating systems work. I’ll have someone with a pretty impressive title reach out to me with a basic OS question, and I wonder how they got to where they are without this foundational knowledge. Most of this stuff I learned on my own when I got my first computer.
There are people here on this forum openly admitting they don’t see how ‘knowing Linux’ is useful, so no point actually learning it.
I have no idea if they really never learn and wing it until they become managers or become great cloud engineers who simply scale up instead of running strace.
I don’t know how someone uses modern dev tools without understanding some very basics of the Linux CLI. I see this all the time. If a command in some documentation isn’t a straight copy/paste, they’re done for.
Knowing Linux is different than knowing how to use a CLI.
I dislike that the two are conflated.
Firstly, Mac and Windows both offer a very mature command line interface.
But also, I don’t think knowing Linux should require you to know the command line either. If other operating systems don’t require it, neither should Linux.
If you’re focusing on “developer tools”, even then, what tools do most devs need that can’t be done from a UI? I live a lot of my time in the terminal but there’s very little that can’t actually be wrapped in a UI
all your points are valid, and you don't "need" the knowledge but it sure feels like the UI can get in the way of some things, mislead your formation of a mental model, or reduce the clarity & density of information. I find most source control tools with mouse-driven UIs like this.
I think CLI tools can help compartmentalise functionality and that can be helpful.
But I think they can also obscure functionality the same way as a GUI tool.
Take git for example, it’s much easier to visualize how it works from a GUI. Squashing is also faster in a GUI. But some other operations are clearer when you’re giving every flag yourself.
Ultimately I think it comes down to the UX of something regardless of the form of UI it’s presented in.
Let me flip that around on you: why would someone need to know Linux specifically for the majority of jobs out there?
I’m very familiar with Linux. My day job for years was Linux based and I honestly do not think one needs to know it, or any other OS specifically , unless your job specifically requires it.
Your question is a trap because you’re not qualifying what type of job you’re talking about. I could say “because your code runs on Linux and you should learn it” and then you’ll just say “well I wasn’t talking about jobs writing code running on Linux”.
Assuming the discussion is about a typical developer that runs code that is deployed to “the cloud”, and the cloud is basically 99% Linux, yes. You absolutely need to know enough about how Linux actually works to be effective at your job. Otherwise you’ll fall into the sort of trap zillions of “big data” engineers fall into, where you spend countless hours writing custom code that takes up terabytes of RAM that could have been a simple sed/awk/grep pipeline that uses a handful of kilobytes.
Surely, if my question is a trap then so is the initial premise I’m replying to?
It doesn’t specify a job and that’s exactly what I’m calling out.
Even your response assumes that a “typical” developer is one who deploys to the cloud , but what is that based off of? And how many of those need to interact with the cloud infrastructure itself?
Your second point about taking up terabytes of RAM doesn’t really matter if it’s on the cloud or not, and certainly doesn’t matter if it’s Linux . It’s also assuming that you can’t have a UI frontend that just calls the necessary efficient code or CLI commands behind the hood.
So my question remains: what percentage of jobs actually require you to know Linux specifically?
We can apply the principle of charity and assume that because OP was making this complaint at all, it was probably in the context of jobs where ostensibly there is plenty of value in learning Linux. You don’t need to ask for qualification here, it’s just assumed by context that, for OP’s point, these were probable roles that really should have Linux knowledge.
But you turn that around and say “but why would you need Linux knowledge??!”, taking the least-charitably-possible interpretation of OP’s comment, as if they’re talking about janitors or something, challenging them to prove why the majority of jobs (!!??!!??) needs Linux knowledge.
I dunno man, maybe because in their head they’re referring to a category of people for whom working Linux knowledge really should be expected, and it’s assumed that readers of their comment will probably understand that, and that they’re not going to be prompted to qualify every last thing they say.
But sure. Yeah. Linux technically refers only to a Kernel and not the whole OS so people shouldn’t say “learning Linux” if they only mean a CLI and a basic unix-like environment. You’re very smart, thank god you’re here to clarify all of this for us.
I need to stop with HN for a while, the level of pedantry has gotten absolutely out of control and I’m getting angry just reading this shit.
> There are people here on this forum openly admitting they don’t see how ‘knowing Linux’ is useful
That could literally apply to any job, especially as a developer.
And then the rest of your inane rant is about something I didn’t say. I didn’t say anything about linux being limited to the CLI, in fact my other comments say Linux is much more than the CLI.m. So now you’re just inventing your own argument to be angry about.
So maybe take your own advice, and give a charitable reading instead of getting angry because you’re unable to make a point. Because not only did you take the least charitable version of what I said, you invented arguments I didn’t make.
And maybe you should take a break from the internet if things make you this angry this easily.
Yes, I wasn't specific enough: it comes from developers. I can see how frontend devs don't want to 'learn Linux' but not wanting to learn how to configure an HTTP server because 'this is Linux' is at the very least poor taste.
Now, talking about people who actually deploy code to backends... these are the folks I had in mind. I imagine most of them don't deploy to Windows Server and they sure aren't deploying to any macos backends.
I think you’re arguing backwards from the assumption that people aren’t learning those skills because it’s Linux versus the actual learning of the skill itself.
Why would a frontend dev need to know how to configure a http server beyond what node or wamp/lamp gives them?
The number of full stack people is very low compared to dedicated backend and frontend folks. People focus on the needs of their job, and if their job doesn’t require wearing both hats they usually don’t go out of their way to do it.
Even at many companies that deploy things to the cloud, they’ll have dedicated folks for that because the people writing the code to run are busy writing the code.
That it eventually runs on Linux is not very meaningful to most devs unless their app needs special compiling configurations or libraries.
Re frontend devs not knowing how to configure an HTTP server: it's literally the front end. Caching, cors, cookies, maximum request sizes, these are all things frontend devs should know to work effectively as a team with the backend folks, but the backend folks gladly help out, usually. I'm not even saying they should know basics of DNS even if I think they should if they want their work load into their customer's browsers quickly. I can accept the browser is the OS and whatever happens outside of it is dark magic, like I said it is just poor taste.
> Even at many companies that deploy things to the cloud, they’ll have dedicated folks for that because the people writing the code to run are busy writing the code.
And this is the root of the problem. A week's worth of coding sure saves them a day of configuring their host systems, not to mention optimizing their cloud spend up. The folks who actually know how the system works and how to diagnose when it doesn't are in short supply and are also effin busy.
> That it eventually runs on Linux is not very meaningful to most devs unless their app needs special compiling configurations or libraries.
This is true only until it isn't. There can be times of coasting and then the dreaded base image version bump comes and 90% of the organization has no clue if they're impacted or how to check if they are.
But most frontend devs don’t need to do any of the things you’ve mentioned. By your own comment, they have a backend team who handle it and they work in concert. Would it be nice if they could understand each other better? Sure but most backend folks aren’t picking up JavaScript and UI frameworks either , or learning about browser tech.
And all the stuff you mentioned can be done by learning those skills on windows or Mac. Linux doesn’t really need to factor in, and now you’re saying to learn an entirely new operating system in addition to a new skillset.
You’re trying to say they should be more than what they are, but for a scenario they can’t predict coming up? In which case any number of other things might happen too, and there is likely already a team of people better suited to handle those issues. What would the sales pitch be to have someone learn it?
I think there’s an impedance mismatch between what you expect to provide value to someone as a hypothetical future goal and what they actually need to achieve their objectives.
The sales pitch is the difference between being a programmer and an engineer: one writes code, the other solves business problems. The value delivered by good engineering may be less than a lucky coder who doesn't have time to learn the tools of the trade, but this is expected: engineering is making sure luck doesn't matter for the business, within the operational envelope and in the assigned budget.
Linux is important if that's what the backend deploys to. If it is, it's a part of the operational envelope - I am saying engineers should have familiarity with what production is running on. I don't particularly care where those skills are being picked up as long as you know that on the production box there's strace instead of dtruss and you know how to check what the D state process is waiting for or whatever interesting issue arises which only happens under load, with networked storage and with at least a couple dozen cpus. (This is also why I don't care for frontend devs to 'know Linux', but having some knowledge about HTTP and their production HTTP servers would be beneficial, as would be knowing that networks aren't magic...)
That seems to be the “or” thinking. How about And. And when you away from desk like in the sub (us) or train (uk), you can have a look and test or just study a part of the code you have troubled to debug, understand or learn.
At the same time, some “developer” might like to stay in one Env. Sadly there is no dual Env for mac, and windows tablet mode …
Exactly, it's mostly a laptop, so it's my main driver when at home. No inconvenient keyboard in the way when consuming media on the couch, but very productive when coupled with a (mechanical) keyboard, mouse and external display. Getting my ipad is no bother, getting my laptop is.
iPad Pros have a very capable (and expensive) keyboard which doubles as a great stand. BLE keyboards and mice can be paired with an iPad. Wired keyboards also work.
I often see my dad use his iPad in keyboard/mouse mode. At this point I question the point of the iPad. It seems like the user is seeking to interact with it like a laptop, yet the OS is far more compromised than macOS. Window management isn’t as flexible, all apps need to come from the App Store, things that power users would generally want (like Terminal) aren’t there for the native OS, Files is less capable than Finder, and the entire OS is build around apps rather than files, which makes working on a file across multiple applications more difficult.
I think my tech life would be more simple if I could use an iPad as my computer, but I can’t see a path there. I’d have to give up too much.
I program for a career and I’m not going to argue that iPad is going to be my go to device, until there’s a ‘killer’ app. But that’s my day job. When I want to play around with a hobby (writing, music, game dev using Godot???) I turn to an iPad because it’s NOT a computer. Maybe in the same way a lot of music hobbyists buy gear to make music even though using a computer DAW is far easier - we want to ‘unplug’.
Same here. I used to have Linux on my iPod and Xbox, MythTV running on a server and Fujitsu netbook. Now between the hockey rinks and soccer fields, I take out my iPad Pro for HN, light photo editing and Netflix if I’m lucky enough to find an hour of down time. There’s enough Linux, QNX, Windows, FreeRTOS, Azure, etc etc all day at work now.
I use the iPad for several reasons.
- I can remove the keyboard when I don't want it.
- When I want it I can use keyboard, trackpad, mouse and a Pencil, something a Mac does not have.
There are power users out in the world that never use a terminal because that's not their line of work. I use the Affinity suite of apps, most notable Affinity Publisher for layout and design work. I regularly design annual reports, newsletters, any number of print materials ranging from brochures, posters, banners, bookmarks, etc. All of it. And I do it all with the iPad and whatever input I want/need at the moment. No problem.
Additionally I use the iPad along with Textastic to code websites the old fashioned way, basic html and css. I started experimenting using the iPad for those particular jobs in 2010. When I sold my MacBook Pro in 2017 I switched to the iPad for all of my new website set-ups as well as website updates for existing sites. Textastic is great for that and I've had no problem.
Last, I do spreadsheet work for a client who runs a retreat center. I process thousands of records per year, managing contacts, retreat signups, mailings, etc all from the iPad and with no problem.
When I want a break or at the end of the day I set the keyboard to the side but within reach.
Another point worth mentioning that I think often goes overlooked by those that don't use the iPad is the variety of interesting set-ups that can be created with it. Because it's not attached permanently to a keyboard it can be easily attached to a multi-arm stand and swiveled to different angles and heights. Just one example. I've enjoyed experimenting with all sorts of different useful arrangements.
The iPad obviously isn't for everyone or every task. But it's kinda bonkers how many people who don't have a use for it themselves just assume that no one else could possibly put it to use.
For those who have a use for the touch screen, like drawing, I get it.
I was thinking more about people who solely use the iPad docked with the keyboard and trackpad.
I’ve had 6 or 7 iPads. They all end up sitting around with a dead battery after a while, because all I ever want is a keyboard and mouse, and at that point, the laptop is easier to deal with.
If you're looking at this from the perspective of a power user, then sure. For everyone else, the iPad makes a robust computing device that simply does not have a lot of complexity that we power users have just learned to accept. Try explaining the concept of "files" or "terminals" to a random person on the street.
Considering files have been at the center of how operating systems work since the beginning, and computers have been used in school and businesses for 30 years now, I find it disappointing that people are still confused by files.
When people were confused by the keyboard, Jobs said that death would take care of that. When it came to files, he saw that as a problem that needed to be solved in the system, but I think it is more confusing on the iPad than macOS.
People have had to use files, moving them to floppy disks, burning them to CDs, copying them to flash drives, and now dealing with them with services like Dropbox. I would think files and folders in a home directory would be something people understand now. I think the modern smartphone and tablets made a lot of people regress, and the youngest simply aren’t learning it. The less it’s used directly, the abstract the idea becomes, and that makes systems harder to use, because at the need of the day it’s still files and folder. Avoiding that has so far created confusing layers of abstraction that haven’t worked so well.
> When it came to files, he saw that as a problem that needed to be solved in the system, but I think it is more confusing on the iPad than macOS
I completely agree, and I think this is probably iOS' single biggest design mistake. In trying to hide away difficulties non-power users face managing a filesystem, they've managed to make things both more confusing for novice users and just plain annoying for power users.
I think the issue is that most computer users do understand at least a little about filesystems. They might lose things or accidentally delete or overwrite things, but I think many many people are reasonably okay with the concept "my things are in files, my files are in a folder".
But the app-centric model iOS uses becomes unnecessarily difficult when you need to do anything with a file that extends beyond viewing it in the software that created it. Emailing or copying a file is an incredibly common thing to need to do, yet some of the most technophobic people I know can manage it just fine on a PC because the process is the same for any and every file. The hardest part for them is usually just remembering where they put it.
That one problem is solved by an app-centric file model, but introduces a much bigger problem in that the mechanism to share or copy a file is different for every app! It might be under an "export" option, or it might be under a little abstract picture of a square with an upwards pointing arrow—because of course, everyone universally understands that square-with-upwards-arrow is how you email this to Steve in accounts...
(Yes the share icon is fairly standard across iOS apps, but it could be and is located all over the place, and I'm not convinced it's intuitive that step one of "emailing a document" is "open Word").
When was the last time you used an iPad and the Files app? It seems like your view is somewhat outdated. It's true that in the early years the Files app was very basic. But there were some significant improvements introduced around iPadOS 15. As of iPadOS 17 it is a far more robust app that is much closer to the Mac's Finder in terms of visual design and features.
I regularly manage thousands of files in nested folders of website projects as well as Affinity Publisher documents in nested project folders, each with hundreds of linked asset files. And this also includes regular use of local network drives, external drives and sftp accounts for websites.
And many apps are now much more flexible in terms of opening and saving files in locations other than the default. It's not identical to the Mac Finder and there are occasional oddities but in my experience it is very capable. But it's nothing like what it was 10 years ago.
It's easy to say that files should be easy to understand by now but for a lot of people who aren't necessarily computer natives, there is a non-trivial learning curve as to what a "file" conceptually is: something that's on a storage device, that's in a specific part of some abstract folder tree, that is required to have a name, that has a type that may or may not in the name (file extensions), that has a format that some programs understand and others don't, that has an associated program or programs that know how to open it, that can be copied and that copies are in no way connected to the original that may be found in different locations to the original, etc.
Contrast that to how iOS just generally leaves applications to "own" their own data and present them however makes most sense, with only a few exceptions (the most notable being the Photos app, which sorts and displays photos by things that make sense for photos). The place where you'll find the thing you were working on is actually just in the app where you were working on it, which is, unsurprisingly, far easier to explain. Plenty of people get on perfectly fine without knowing or caring about "files" and are not really worse off for it.
I have a hard time accepting that some of those are what trips people. That a something called “file” is in one place (device or particular location) seems more readily understandable than an ethereal thing that’s (sometimes, to some degree, at some resolution) ubiquitous.
The format topic is also something that I see causing frustration, but it is not complicated to understand, as long as someone is familiar with the concept of incompatibility (screwdrivers, human languages, etc.)
In my opinion at this day and age is more an issue of “never needed to learn / cared to” than that of “it is difficult to learn”.
Okay, I'm going to take a hard disagree on this point. Apple's "abstraction" for viewing files is really not that deep. If you open the Photos app, you are looking at a bunch of files. Garageband showing it's saves, iMovie showing it's projects, iCloud showing it's folders, none of it is a particularly "simplified" view of things. At best, it's rehashing the MIME type filtering mechanism most mainstream OSes have used since the 90s. You really cannot argue that iOS is some different breed of computer when ultimately it's just creating a custom wrapper around things people readily understand.
I didn’t say that iOS is some different breed of computer, I said that it doesn’t present a lot of the complexity. Of course it’s all files underneath but the point is that they are usually presented in a way that doesn’t leave the user thinking of them as “files” as an abstract concept. People browsing through the Photos app aren’t really thinking about file names, whether it’s a JPEG or some other format, what folders they’re in etc. The “abstraction” doesn’t need to be deep to be effective.
That's a very nice combination if you have a relatively static setup for the keyboard and mouse, where you can drop the iPad in and out of it like a dock and take advantage of the modularity.
However—at least in my own experience—if you're carrying the keyboard/mouse/trackpad around with the iPad all the time, I found it robs the device of what makes it compelling to begin with (being ultraportable and handheld).
For a stint I was using an iPad Pro with the keyboard/trackpad case, and it made it a far worse tablet. The case almost doubled the total weight and thickness, which made using it much more like to a laptop, but it isn't nearly as capable as my MacBook (nor is it any cheaper).
More power to you if that setup works for you, but I came to the conclusion that I'd just assembled myself a second, worse laptop (which I think was OP's overall point).
See the second paragraph of the comment to which you replied:
If you're going to use the iPad with a keyboard, why not just use a laptop?
I suppose the use case here is iOS game developers who don't want to use their MacBooks, but iPad+keyboard doesn't seem like a fun way to write complex software to me.
The iPad, and tablets in general, have never been great for productivity. Maybe it is fine for email, but that’s about it. Apple has been careful to not bring any of the conveniences of MacBooks into the iPad, and unfortunately it means the “Pro” versions of the iPad are basically not any more useful than the regular ones. Even simple things like multitasking - copying content between apps or moving browser tabs around or whatever - can be difficult or impossible.
Even if we assume the best intentions, I think iOS and iPadOS is still recovering from being crippled based on early design decisions.
I remember at one of the Apple events Steve Jobs was saying the one area of complexity that still hung people up was the filesystem, so iOS (and as an extension, iPadOS) hid it away from the user. Files were locked to apps. As the platform evolved, people wanted/needed to operate in multiple apps with one file, so this concept of duplicating files in multiple apps came to be. This was a mess when it came to file versioning. It was also very difficult and confusing, and required apps to support it.
Eventually they added the Files app, but it is a very slow road to change over from an app based system to a file based system. Even today, it’s a crap shoot and some apps work better with the Files app than others, and it seems this aspect is still much more confusing than macOS from this perspective.
This was a huge miss that no one really talks about.
When I wanted a replacement for my Samsung Galaxy Book 12 (a 12" tablet w/ a bundled folding keyboard case and included S-Pen) I had to go up to a Samsung Galaxy Book 3 Pro 360 (since that was the only high-resolution device w/ an S-Pen then available) and had to go shopping for a new bag to carry it.
I do use it for development after a fashion (OpenSCAD, https://pythonscad.org/ and sometimes https://www.blockscad3d.com/editor/ or OpenSCAD Graph Editor, usually using TeXWorks for Literate Programming), but also for drawing/sketching and note-taking and annotating PDFs.
And then oversized phones killed tablets, bringing us the worst of both worlds :-P
I was looking into tablets recently and there is a dearth of options - a quick search in a local eshop aggregator has ~20 2024 tablets after i filter out the sucky specs and ~72 2024 laptops (including some larger ones), again after filtering the sucky specs. Meanwhile there are ~276 2024 phones after sucky spec filtering and that is with greater specs than the tablet ones (because the aggregator had no filters matching the tablet specs - even the minimum specs in phones were higher than the high specs in tablets).
All these give me the impression that we're long past the hype days of tablets.
I primarily use an iPad pro. Hardware-wise, I think it’s a superior paradigm. Most of the time I’m using it with the magic keyboard. I love that if the keyboard is damaged, it’s totally removed from the device.
He talks about lack of discoverability of long press, like if you long press on a feature you get a different result vs if you short tap.
One way this could be addressed can be borrowed from video games: animated pie charts, growing as you hold down the button, activating the secondary function only after the pie completes a full circle.
> Educational apps designed to teach, develop, or allow students to test executable code may, in limited circumstances, download code provided that such code is not used for other purposes.
I believe this app would fall under this clause, much like apps like Pythonista and of course Swift Playgrounds (not that Apple even pretends to follow its own rules).
It looks like gdevelop uses JavaScript as it's scripting language so it might just be a browser based thing which apple seems to allow (see Facebook apps internal game market - all browser based)
Is this an open source project? I would like to try this, especially after reading about all the little ux touches, but I wasn’t able to find any links.
This is a pretty fantastic breakdown of UX and UI design, both for porting to SwiftUI but also to smaller screens.
There’s obviously room for polish left but this looks so well thought out already.
I am interested in how this might find its way back to Godot proper. Would the team be willing to maintain not only one more target but also an entirely different UI frontend?
I am also curious if this could become the native macOS frontend. Even if that’s behind a compile time flag, that’s a very powerful option for accessibility.
Lastly, GPL incompatibility aside, I wonder if this could inspire a similar effort for Blender. Blender on iPad would be an amazing value addition.
Almost definitely no to both your questions. Godot doesnt have enough developer resources to work on this, and this repo's value is truly marginal. I really don't see the use case. I think this guy is just having fun.
And if the targeted usage is "iPad with a keyboard on a desk" well, at this point it's mostly a laptop anyway so as a developer why even bother getting a tablet in the first place?