Jay, your note prompted me to test this in another, simpler test app that I have. And of course, it worked fine in that app! But, the levels of nesting of the collections and articles are exactly the same as the problem app. The only difference that I can determine between the 2 is that the app in which I'm having problems the collection is not yet published, where in my test app it is published and out of date. But in both cases I'm preflighting. The other difference is that my navto link is qu...

As I mentioned in my first post, this is happening is custom preflight app builds, built with version 2016.11.The problem exists on iPads and iPhones, but not Android devices.I can verify that I'm using the article name and not the article title. I've tried this with several different articles, just in case there was some obscure problem with the article name, or it was being miss-typed or something.In your tests, did you put the banner on the browse page of the collection that you are linking t...

Ashe, 1.2 worked for the iPhone dual orientation app.I did some testing with 1.4 in a simple, fresh file with 2 breakpoints with just a single orientation test app also, and couldn't get it to work there either. Did all my testing on an iPhone 6 in case that matters.

FWIW, I was never able to get version 1.4 or 1.3 to work with content on an iPhone. Worked great with the same HTML article on an iPad. I tried all kinds of sneaky things to see if I could get it to work, but never figured it out. I ended up using version 1.2, and that worked for the project at hand.

This .mucow is working great for me, except when the article is viewed on the iPhone. The same article works perfect on the iPad and Android, but when viewed on an iPhone 6, the AEM Mobile "chrome" can only be displayed with a "long tap" on the screen. Weird. FWIW, this is a dual-orientation app on the iPhone. Perhaps that has something to do with it? I guess I'm just checking to see if anyone has this working successfully on iPhone dual orientation apps?

Any chance that this is going to add dual-orientation capabilities to Android apps to be on par with the iOS version?

We're having the same problem...starting with 2016.9 build. See my post here: Change in orientation behavior in Android apps Something, somehow, changed with the Android build, but I haven't been able to find any documentation or explanation about this. Bottom line, is that right now all the Android tables that we've tested display browse pages as a large phone.