fastlane: [deliver] Cannot upload iPad 3rd generation screenshots

New Issue Checklist

Issue Description

Despite using snapshot to generate screenshots “iPad Pro (12.9-inch) (3rd generation)-01_screenshot_X.png”, and after battling with the ongoing sizing issues, such as https://github.com/fastlane/fastlane/issues/13698 and https://github.com/fastlane/fastlane/issues/13610 It still uploads the images for “iPad Pro (2nd Generation) 12.9-inch Display” – the problem with this is that all my localisations then go and use English (e.g. https://cl.ly/db4d1a265bbb)

Complete output when running fastlane, including the stack trace and command used
[08:19:18]: Uploading 30 screenshots for language zh-Hant
[08:19:18]: Uploading './screenshots/zh-Hant/iPad Pro (12.9-inch) (3rd generation)-01_screenshot_1.png'...
[08:19:43]: Uploading './screenshots/zh-Hant/iPad Pro (12.9-inch) (3rd generation)-02_screenshot_2.png'...
[08:20:08]: Uploading './screenshots/zh-Hant/iPad Pro (12.9-inch) (3rd generation)-03_screenshot_3.png'...
[08:20:35]: Uploading './screenshots/zh-Hant/iPad Pro (12.9-inch) (3rd generation)-04_screenshot_4.png'...
[08:20:52]: Uploading './screenshots/zh-Hant/iPad Pro (12.9-inch) (3rd generation)-05_screenshot_5.png'...
...
[✔] Saving changes 
[08:23:45]: Successfully uploaded screenshots to App Store Connect

Environment

✅ fastlane environment ✅

Stack

Key Value
OS 10.14.2
Ruby 2.3.7
Bundler? false
Git git version 2.17.2 (Apple Git-113)
Installation Source /usr/local/bin/fastlane
Host Mac OS X 10.14.2 (18C54)
Ruby Lib Dir /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib
OpenSSL Version LibreSSL 2.6.4
Is contained false
Is homebrew false
Is installed via Fabric.app false
Xcode Path /Applications/Xcode.app/Contents/Developer/
Xcode Version 10.1

System Locale

Variable Value
LANG en_AU.UTF-8
LC_ALL
LANGUAGE

fastlane files:

No Fastfile found

No Appfile found

fastlane gems

Gem Version Update-Status
fastlane 2.114.0 ✅ Up-To-Date

Loaded fastlane plugins:

No plugins Loaded

Loaded gems
Gem Version
did_you_mean 1.0.0
slack-notifier 2.3.2
atomos 0.1.3
CFPropertyList 3.0.0
claide 1.0.2
colored2 3.1.2
nanaimo 0.2.6
xcodeproj 1.7.0
rouge 2.0.7
xcpretty 0.3.0
terminal-notifier 1.8.0
unicode-display_width 1.4.0
terminal-table 1.8.0
plist 3.4.0
public_suffix 2.0.5
addressable 2.5.2
multipart-post 2.0.0
word_wrap 1.0.0
tty-screen 0.6.5
tty-cursor 0.6.0
tty-spinner 0.9.0
babosa 1.0.2
colored 1.2
highline 1.7.10
commander-fastlane 4.4.6
excon 0.62.0
faraday 0.15.4
unf_ext 0.0.7.5
unf 0.1.4
domain_name 0.5.20180417
http-cookie 1.0.3
faraday-cookie_jar 0.0.6
fastimage 2.1.5
gh_inspector 1.1.3
json 1.8.3.1
mini_magick 4.5.1
multi_json 1.13.1
multi_xml 0.6.0
rubyzip 1.2.2
security 0.1.3
xcpretty-travis-formatter 1.0.0
dotenv 2.6.0
bundler 2.0.1
faraday_middleware 0.12.2
naturally 2.2.0
simctl 1.6.5
uber 0.1.0
declarative 0.0.10
declarative-option 0.1.0
representable 3.0.4
retriable 3.1.2
mime-types-data 3.2018.0812
mime-types 3.2.2
jwt 2.1.0
signet 0.11.0
memoist 0.16.0
os 1.0.0
googleauth 0.6.7
httpclient 2.8.3
google-api-client 0.23.9
google-cloud-env 1.0.5
google-cloud-core 1.2.7
digest-crc 0.4.1
google-cloud-storage 1.15.0
emoji_regex 0.1.1
io-console 0.4.5
libxml-ruby 2.9.0
psych 2.1.0.1

generated on: 2019-01-22

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 11
  • Comments: 49 (30 by maintainers)

Commits related to this issue

Most upvoted comments

Looks like it’s being enforced now.

Is there any update on this? Apple will be requiring the new screenshots (for 12.9-inch iPad Pro 3rd generation) on March 27th, which is this Wednesday.

https://developer.apple.com/news/?id=03202019a Starting March 27, 2019, all new apps and app updates for iPhone or iPad, including universal apps, must be built with the iOS 12.1 SDK or later and support iPhone XS Max or the 12.9-inch iPad Pro (3rd generation). Screenshots for these devices will also be required.

Looks like this is being enforced on the API now, I’m getting an error when trying to submit an app:

You must add at least one screenshot. There is an error for 1 of your localizations.

Update: no way to deliver iPad 3rd gen screenshots via deliver. Doubling up the ipad screenshots just put 10 in each ipad 2nd gen list.

I’m not really sure how these things work in the open source world

We make it up as we go… 🥇

Seriously: If we can’t figure out a backwards compatible solution to solve this whole mess properly, we will have to either a) introduce fastlane 3.x or b) add an option to switch from the old to the new behavior.

As both things are not really what we want (for a) people will make assumptions about a major verison increase that are just not true, like a lot of new functionality, all the old inconsistencies being fixed etc), and for b) needing an option will leave out new users) I am still hoping we can just find a “different” way to do things that works.

For a workaround that works now: Introducing some code that is triggered by e.g. (3rd generation) in a file name would be fine from a semver view point - it fixes an existing bug with new behaviour. But if Apple ever releases another device with that string in the official name, we will to deal with it then.

Oh so complicated 😕

How are screenshots between these two devices different in appearance?

I guess it’s because the 3rd gen is without a home button, so if you frame your screenshots it should look like the current device you’re browsing App Store on. I had apps rejected previously just because it’s framed in the wrong device (i.e. iPhone 8+ on a iPhone X device or vice versa).

I don’t see any Pull Requests that could be merged that promise to solve this problem 😕 Fastlane is Open Source so that anyone can jump in and help solve any problems or obstacles they may be facing. The people spending more time on fastlane by being part of the team can’t always solve all the problems.

This is a good point. For me the biggest problem working on this issue is, that it seems to be much coupled to other parts of the fastlane. What would be the best strategy to approach this issue? Should one first refactor the whole resolution-logic into a single module (see #14121), or try to “only” replace the auto-detection of “image size” -> “device type” with a less “clever” parsing of the file name.

We could use Apple’s naming scheme as the base, but this would still be a breaking change. This would not only require to rewrite parts of deliver, e.g. AppScreenshot::formatted_name or AppScreenshot::devices, but also other parts, e.g. Screenshot#device_name.

image

As a reminder, starting March 27, 2019 all new apps and app updates for iPhone or iPad, including universal apps, will need to be built with the iOS 12.1 SDK and support iPhone XS Max or the 12.9-inch iPad Pro (3rd generation). Screenshots for these devices will also be required. All new apps and app updates for Apple Watch will need to be built with the watchOS 5.1 SDK and support Apple Watch Series 4. Learn More

It looks like Apple was ready to enforce screenshots on App Store Connect on March 27, but they haven’t actually enforced it yet because when I attempt to create a new submission, screenshots for the iPhone XS Max and 12.9-inch iPad Pro (3rd generation) are still optional (see below).

image

I’m guessing this could happen at any moment? Or never? 🤷‍♂️

@hnakamura-fsv You mean using the technical device identifier (instead of something the API or App Store Connect uses)? Interesting idea, although I always hated how there are multiple per device and e.g. iPad6,11 is actually an iPad 5… Confusing much 😕 But at least consistent and independent from whatever the API uses, so that’s a plus.

Oh so complicated.


What do you all think about maybe adding something like https://github.com/fastlane/fastlane/issues/14474#issuecomment-482047639 as a temporary workaround to just enable all fastlane users to upload their apps with full metadata and screenshots again?

Looks like this is being enforced on the API now, I’m getting an error when trying to submit an app:

Fwiw, I just got off the phone with apple developer support and they’re not even aligned on what’s supposed to be enforced right now. Their first response was that the 3rd generation screenshots are required and the 2nd gen are optional. But when I informed them that that’s not how Appstore Connect is enforcing things right now (both 2nd and 3rd gen are currently required), they looked up the “official” (read: public-facing) support docs and then stuck with the line that both are required. I tried to point out the redundancy in this requirement but was told to file a bug report through “Bug Reporter” which I’ve done. Who knows if/when this will change though

If history is any indication of the future, at some point the 2nd generation screenshots will no longer be required and the 3rd gen screenshots will be.

But this is all just to hopefully provide folks some sanity as they are trying to reconcile all of the changes here. As of right now, it looks like fastlane is unable to submit iOS apps through Appstore Connect because of the new requirement of 3rd gen screenshots 😦

Looks like App Store Connect is enforcing it, but the API isn’t? 🤔 We’ve managed to submit apps without all the required screenshots via fastlane, despite App Store Connect states they are all required.

Hey guys, any updates on this issue? I think this will cause problems once March 1st rolls around and iPad 3rd generation screenshots become required in appstore connect

Huh? Could you please create a new issue @petekanev and provide more information? That should be investigated.

I had a go at implementing a change that allows you to nest screenshots within folders named after each device_type as suggested previously (I.e /screenshots/en-GB/ipadPro129/image.png)

I uncovered a lot of things that made it hard to achieve the desired change without being sure that I’m not introducing regressions though

A rough version can be found here for reference: https://github.com/liamnichols/fastlane/compare/master...experimental-fix

My plan is to try and introduce the changes in small and testable chunks but I’m not really an expert with ruby so this is going to take a bit of time

The first two parts however are #14533 and #14574

something like this could also be an option to map the device id to folders and/or screenshot types - it might be more reliable than going with the device name itself since it can potentially change with renamed simulators etc

Any news?

@jnbt Yep, that is what makes it so hard: We have the upload part in deliver, the screenshot taking stuff in snapshot, and also some framing and positioning stuff in frameit.

In theory it would be enough if deliver somehow could upload the correct file to the correct location in a first step though. Maybe this could help to limit the scope of necessary changes and see how we can solve that.

Of course we optimally don’t want any breaking changes at all. Making people change their screenshot names might be a valid option though (but that would also apply for downloading existing screenshots then - which is another complication).

I will try to spend some time thinking into this tomorrow… I gave up in January, but maybe now I can get further. Will document here as usual. (Please don’t take this as a “You don’t need to do anything” - all help or suggestions are welcome. I would love not to have to think about this again 🙈 )

As I understand, currently we have 2 blockers: no frames from a Facebook design team and frameit can’t detect screenshots for the iPad pro 3rd gen. I solved the first problem with Apple’s marketing images. if you need asap to do screenshots, you could use my solution. it’s not perfect, but better than nothing https://github.com/pingwinator/frameitIpadPro

Not almost identical, completely identical. Super weird. Maybe down the road they’ll change it so the 3rd gen size is the required one. Will report back tomorrow if doubling up works.