And then you have many independent developers who manage to create iPad, Watch and macOS versions of their apps in addition to iPhone.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Instagram CEO Says iPad App Hasn't Been Made Yet Because 'We Only Have So Many People, and Lots to Do'
- Thread starter MacRumors
- Start date
- Sort by reaction score
Yeah! That was the lamest excuse I’ve ever heard. Unless they still are a garage-based operation.
I had a developer Interview at Facebook and I said how poor the Instagram app was on iPad...
It runs as a 3g iPhone app or similar. I said I could fix that and improve it a lot just by setting up the start up info correctly. Take no more than a day..... I said for the sake of a days work it would reflect so badly on all those users....
Facebook Guy said no one used iPad !
I know they maybe don't use it in the street taking photos but ~100 million of people use their iPad before going to sleep.... they aren't taking photos just looking at what's been posted.
I wonder what the add revenue is on all those users?
It runs as a 3g iPhone app or similar. I said I could fix that and improve it a lot just by setting up the start up info correctly. Take no more than a day..... I said for the sake of a days work it would reflect so badly on all those users....
Facebook Guy said no one used iPad !
I know they maybe don't use it in the street taking photos but ~100 million of people use their iPad before going to sleep.... they aren't taking photos just looking at what's been posted.
I wonder what the add revenue is on all those users?
The first huge win would be to get it to use the whole screen on iPad so it would be the iOS app but using the full screen. That takes about 30 minutes to a day of programming. I guess it may take a bit longer to tidy any rotation issues, but guessing they already support all the different size phones so it would just be
In like a bigger phone. This would give you 75% of the benefit of the iPad. Addding other features would be rapidly diminishing returns and start taking more time.
Last edited:
Facebook literally couldn’t care less about the user experience. I’m surprised Instagram has system-level dark mode because Messenger implemented the controls within the app and it doesn’t use iOS preferences.
oh dear.... well that’s cost them... anyway they must support scaleable main window as Apple phones are all different sizes. So just scale for iPads too...it really isn’t hard... testing will take much longer.
That is such a bizarre mindset. There are millions of iPads. They honestly think people wouldn't want to look at the photos and stories they also view from their phones?
It really seems like FB tries to work around every Apple UI element. They even designed their own notification pop ups.
Like the devs who don’t use Auto Layout. They think they have a “better” way of doing it but it’s just harder, unsupported and probably will fall apart.
[automerge]1581968098[/automerge]
Someone in the 9to5 comments proposed the idea that FB knows people use their phones the whole day and iPad intermittently so they don’t want to contaminate the data pool with outlying usage data, and that makes sense.
Yes and no. If this is a standard UIKit app, the argument holds little water because the best case argument there is that it’s then they just need to tick a few boxes, change some constraints and switch a few api calls to get larger images. If however it’s built with some weird Facebook frameworks controlling the UI it’s probably way more convoluted. Still no excuse though as others have noted they really should have the resources to do this.
As an aside to this. Don’t all apps submitted to store require an adaptive layout from 31st of March? This should mean one should appear soon anyway. So this is probably pre-launch slow hype-up being PR’d early to drum up attention so they can do a big reveal?
Adaptive layout: an app store requ… | Apple Developer Forums
What a bunch of horse-pucky!
I am an app developer. I typically help create apps for Enterprises (which are not released on the App Store) but have also done App Store apps. Although I have done native development in the deep, dark, past, currently I only do mixed-hybrid app development.
There is absolutely no good reason why apps today should have any difficulty adapting to different screen sizes, and doing it well. The easiest - and I would say best - way today is to use some sort of hybrid app architecture.
Hybrid app architecture is where you use a WebView for UI. This is basically the "innards" of the platform web browser, minus the "chrome" (URL bar, buttons, and such).
There are frameworks for this (for example, Phonegap/Cordova, RhoMobile). I'd GUESS, though, that today most hybrid apps consist of a true native app that embeds a webview for UI Almost every news app you might use uses some sort of hybrid architecture, and UI is in a WebView using HTML/CSS/JS.
Hybrid got a bad rap early on, because performance was poor. There was the "300 mSec click" problem, which has long since been solved. There was/is the fact that Javascript code in the webview is blocking - the UI is blocked until any callback function completes. (But there are Web Workers if you want to get fancy). There WAS the issue that on iOS UIWebView didn't/doesn't do JIT compilation to machine code like the platform browser does. (But now there is WKWebView, which does).
All of these problems have been solved. The mixed-hybrid solution I use separates business logic from "front end" UI code and doesn't use Javascript in the webview for business logic, network communication, etc.
The advantages of using a WebView/hybrid approach:
- Designers can use the tools they already know - HTML/CSS/JS and directly participate in development, rather than "throwing the design over the (cubicle) wall" to developers, who then ATTEMPT to make screens look like the designers had intended
- Existing JS and CSS frameworks/libraries can be leveraged. For example, I typically have used Bootstrap 4 CSS framework
- Many applications benefit from a uniform look across devices. "Native look and feel" is NOT all it is cracked up to be for MANY types of applications. Do you want a fleet of delivery drivers or field service technicians where half of them have an app that looks one way, and half have an app that looks and work entirely differently? (That said, many apps DO benefit by looking "native" - typically consumer-facing apps of more general utility.)
- Modern CSS makes it very easy to adapt UI to different screen sizes and shapes, and there are zillions of web designers who know how to do so
- It is very difficult to do simultaneous release of updates to pure native apps. They are almost always (as a practicality) developed by separate teams. Deadlines will drift. So, you have two apps with two sets of functionalities and two sets of bugs.
- Native development is difficult, and native developers are expensive. Hybrid is a more affordable approach
- That said, Facebook isn't doing native development. (Other than in the React Native platform itself). But React Native developers are at least as expensive as native developers. It is a steep learning curve. There is a shortage of developers who know it. And (IMO) they are all getting punked into putting a lot of effort into learning a platform that will soon be obsolete. Ouch, ouch, ouch, what will be the next set of expensive Boot Camps they will have to go through to keep up? But, hey, for now they are well-paid.
----
Facebook ABANDONED hybrid development right at the time when it's drawbacks had just been solved. They designed their own tremendously complicated approach (React Native).
React Native uses it's own layout engine and uses true native widgets, but does implement CSS. THEIR OWN brand of CSS! Noooooo.... you can't just drop in, say Bootstrap 4 CSS. (And to my knowledge, nobody has created an adaptation.) It does use an HTML-like XML syntax, but, again - their own take, NOT HTML. I mean, why would you use something that millions of designers know how to use?
React Native follows the stupid "your layout is in your code" approach that has become so common today. Further reinforcing the unproductive "throw the design over the wall" approach.
React Native does provide a uniform framework over native SDKs.
I think developers are making a mistake jumping onto the React Native bandwagon - so many developers are chasing what they seem to thing is "the next big thing". IMO, React Native is already past it's prime, not a thing that is needed today.
React (web framework) as well - and even more so. React was (I always use the term "was" when referring to React/React Native!) an interim solution moving toward Web Components. Guess what? Web Components are here. And they are viable to use inside of Web Views.
----
The "you need to use native code to get good performance" advice is long obsolete. No, you don't. For most apps, it only complicates things and makes app development MUCH, MUCH more costly!
[automerge]1581972365[/automerge]
Bingo! See above.
I am an app developer. I typically help create apps for Enterprises (which are not released on the App Store) but have also done App Store apps. Although I have done native development in the deep, dark, past, currently I only do mixed-hybrid app development.
There is absolutely no good reason why apps today should have any difficulty adapting to different screen sizes, and doing it well. The easiest - and I would say best - way today is to use some sort of hybrid app architecture.
Hybrid app architecture is where you use a WebView for UI. This is basically the "innards" of the platform web browser, minus the "chrome" (URL bar, buttons, and such).
There are frameworks for this (for example, Phonegap/Cordova, RhoMobile). I'd GUESS, though, that today most hybrid apps consist of a true native app that embeds a webview for UI Almost every news app you might use uses some sort of hybrid architecture, and UI is in a WebView using HTML/CSS/JS.
Hybrid got a bad rap early on, because performance was poor. There was the "300 mSec click" problem, which has long since been solved. There was/is the fact that Javascript code in the webview is blocking - the UI is blocked until any callback function completes. (But there are Web Workers if you want to get fancy). There WAS the issue that on iOS UIWebView didn't/doesn't do JIT compilation to machine code like the platform browser does. (But now there is WKWebView, which does).
All of these problems have been solved. The mixed-hybrid solution I use separates business logic from "front end" UI code and doesn't use Javascript in the webview for business logic, network communication, etc.
The advantages of using a WebView/hybrid approach:
- Designers can use the tools they already know - HTML/CSS/JS and directly participate in development, rather than "throwing the design over the (cubicle) wall" to developers, who then ATTEMPT to make screens look like the designers had intended
- Existing JS and CSS frameworks/libraries can be leveraged. For example, I typically have used Bootstrap 4 CSS framework
- Many applications benefit from a uniform look across devices. "Native look and feel" is NOT all it is cracked up to be for MANY types of applications. Do you want a fleet of delivery drivers or field service technicians where half of them have an app that looks one way, and half have an app that looks and work entirely differently? (That said, many apps DO benefit by looking "native" - typically consumer-facing apps of more general utility.)
- Modern CSS makes it very easy to adapt UI to different screen sizes and shapes, and there are zillions of web designers who know how to do so
- It is very difficult to do simultaneous release of updates to pure native apps. They are almost always (as a practicality) developed by separate teams. Deadlines will drift. So, you have two apps with two sets of functionalities and two sets of bugs.
- Native development is difficult, and native developers are expensive. Hybrid is a more affordable approach
- That said, Facebook isn't doing native development. (Other than in the React Native platform itself). But React Native developers are at least as expensive as native developers. It is a steep learning curve. There is a shortage of developers who know it. And (IMO) they are all getting punked into putting a lot of effort into learning a platform that will soon be obsolete. Ouch, ouch, ouch, what will be the next set of expensive Boot Camps they will have to go through to keep up? But, hey, for now they are well-paid.
----
Facebook ABANDONED hybrid development right at the time when it's drawbacks had just been solved. They designed their own tremendously complicated approach (React Native).
React Native uses it's own layout engine and uses true native widgets, but does implement CSS. THEIR OWN brand of CSS! Noooooo.... you can't just drop in, say Bootstrap 4 CSS. (And to my knowledge, nobody has created an adaptation.) It does use an HTML-like XML syntax, but, again - their own take, NOT HTML. I mean, why would you use something that millions of designers know how to use?
React Native follows the stupid "your layout is in your code" approach that has become so common today. Further reinforcing the unproductive "throw the design over the wall" approach.
React Native does provide a uniform framework over native SDKs.
I think developers are making a mistake jumping onto the React Native bandwagon - so many developers are chasing what they seem to thing is "the next big thing". IMO, React Native is already past it's prime, not a thing that is needed today.
React (web framework) as well - and even more so. React was (I always use the term "was" when referring to React/React Native!) an interim solution moving toward Web Components. Guess what? Web Components are here. And they are viable to use inside of Web Views.
----
The "you need to use native code to get good performance" advice is long obsolete. No, you don't. For most apps, it only complicates things and makes app development MUCH, MUCH more costly!
[automerge]1581972365[/automerge]
Bingo! See above.
Last edited:
This is probably the truest answer.
Instagram us all about “Instant Gratification”. They want the app ON your phone so you have to DO shiny things and people can see you DOING them. They do t want curated pictures, they want “Instant” ones.
also that sweet, sweet mobile data to mine the crap out of. all the people walking around with the app live provides gigs of useful data.
If everyone uses an iPad, then you’re not usually taking the pics LIVE. Your not “DOING” the thing that drives hype. nobody walks around with their ipads out all day to instant check things. Then they lose that sweet, sweet data from phones everywhere.
Odd excuse coming from a CEO. Par for the course coming from middle management.
I'm not a developer. But aren't there ways (Swift?) to build/compile apps that run on both iOS and iPadOS?
I'm not a developer. But aren't there ways (Swift?) to build/compile apps that run on both iOS and iPadOS?
Ha!!
This is likely the most accurate answer. Hence the middle management-calinber "we're too busy" response.
You don’t think Zuck isn’t hard at work on the same thing? You’re not giving him enough credit!
You’re one of the biggest social media platforms, not a startup.
Seriously though I suspect part of the reason is that the compressed images won’t look great on a bigger screen.
Seriously though I suspect part of the reason is that the compressed images won’t look great on a bigger screen.