So I made the "mistake" of upgrading one of my devices to iOS 14 (currently iOS 14.0.1), which I found out that now I can NO longer deploy to that device via xCode, since I am still developing with xCode 11.7 and not the newest version of xCode 12.
I am still able to deploy to the device with iOS 14, because of utilizing testflight, regardless of it being on the newest iOS, but I am getting some really weird results!!
This is what the screen SHOULD look like, which is running on a device with iOS 13.7:
versus the result when the device is on the newer iOS 14.0.1 version:
Has anyone else witnessed this!?
Couple of questions:
How does the text go from black to blue!?
The main image is all blue vs rendering the true image!?
In the case of the picker for "Origin" the image of the country flag is also all blue vs rendering correctly?
Is this the expected behavior of any app that is uploaded for sale in the iTunes Store which is compiled under an older version of xCode, my case xCode 11.7, vs the newest version?
I mean in the instance any person downloads the current version of the app created in an older version of xCode, but that user has the newest version of iOS on their phone, will the app become all messed up like that!? If so, what was apple thinking!?
Can anyone else provide ways they got around it, or what they experienced?
*** UPDATE ***
Providing the code for the text fields and pickers:
Here is the "default" Textfield:
TextField("Cigar Name", text: $model.cigarName)
Here is the code for the custom picker:
NavigationLink(destination: CountryPicker(cCode: $countryCode, cName: $countryName)) {
Text("Origin")
if countryCode != "" {
Spacer()
HStack() {
Image(uiImage: UIImage(named: "CountryPicker.bundle/Images/\(countryCode)")!)
.clipShape(Circle())
Text(countryName)
}
}
}
Code for "default" picker:
Picker(selection: $selectedCigarStrength, label: Text("Strenght")) {
ForEach(0 ..< cigarStrength.count) {
Text(self.cigarStrength[$0])
}
}
*** Latest Update ***
So I got my new MacBook and d/l xCode 12 for deployment to iphone with iOS 14.0.1 and this is what the screen shot looks like in comparison:
As you can see it looks way different!!! Good news is that the blue images went back to rendering the correct images in the sheet.. bad news is that the text is still blue!? I guess developers will have to strictly specify the text color going forward!? Which is weird... if no color is declared I would imagine it should stay .black by default... as it did in all other versions of xCode!?
Notice too that the form does not extend to the edge of the screen anymore and the date picker has really changed (which I actually like, finally something they actually improved in the new OS).
Me2 but I do not have a solution. I switch back from xcode 12 to xcode 11.7
Based on the issue perhaps it should be the defaults textColor property changed by the system, if possible, please show the code about the textColor for UILabel.
It would seem that iOS 14, for me 14.0.1, has serious issues with colors!?
As noted above, now it would seem that you need to be explicit with the foregroundColor for Textfields and text alike and "force" them to a default color of black, as that used to be default... not sure why they changed that!
The same thing goes for Navigation titles (navigationBarTitle), if you move from one tab that utilizes the title to another tab which does not require it, it will not remove the navigation bar title in the new view for some reason, UNLESS you "trick" the system with navigationBarTitle("") other wise force the blank title.
Not sure why apple decided that everything needs to be explicit vs implicit as it was in the previous xcode and ios versions!?
Another, which I think is a biggest issue, I have uncovered is the evaluation of the Nil-Coalescing Operator.
I have the following condition:
Button(action: {
if (self.viewRouter.currentView != "menu") {
self.viewRouter.currentView = "menu"
}
}) {
Image("menu")
.renderingMode(.template) //**** REQUIRED!!!!
}
.foregroundColor(self.viewRouter.currentView == "menu" ? .blue : .gray)
This simple condition states that if the view currently clicked on is the "menu" then the color of the button should be blue vs if its not and a different view is being displayed it should be gray... the end result is that the button is black and no matter which I select in the tab bar they all remain black and not not change color as they do on my device that i am running iOS 13.6!?
*** UPDATE ***
Again ios 14 became a lot more explicit!! you need to add the .renderingMode(.template) in order to achieve the same result in the pre-ios 14 era.
Related
This issue is for Xamarin iOS apps built in Xcode 14.0 and running in iOS16.0.
Where a page title is set other than in the page constructor (for example in OnAppearing), the page title is not shown - missing - when first displayed. If you push out of the page and later return to it, now the title will be displayed.
This appears to be caused by an Apple bug in iOS 16.0 / Xcode 14.0. Two ways to work around it:
Move your title-setting code to the page constructor.
Leave the title-setting code where it is and add the following to the page constructor:
Title = "\uFEFF"; // Non-printing non-blank Unicode character
Apparently, if the Title is null, empty or blank in the constructor, the alpha of the text is set to 0.
No doubt Apple will fix this in later versions, but the problem remains for the current versions I believe.
I have developed a SwiftUI NavigationSplitView app with two columns and it works as expected.
I have chosen dynamic fonts and crafted the visual elements to respond to user settings
for visual accessibility. I know that a number of the users who will employ this app will have
the font size set to the largest available. While that enhances their view of the detail
screen, it pretty much makes the sidebar unreadable. I'm trying to find a way to change
the app's behavior based on the size of the dynamic type. Specifically, I'd like to have
the iPad behavior the same as an iPhone behavior based on a font size that I define.
As it is, the app on an iPhone collapses to a single column. I have not been able to
find a way to programmatically do this on an iPad.
I have tried:
Setting the horizontalSizeClass and as expected, this is a getter only.
.horizontalSizeClass = .compact
I have tried setting the column width of the detail to 0.
.navigationSplitViewColumnWidth(0)
that does not work
I have tried using the old stack function.
.navigationViewStyle(StackNavigationViewStyle())
that does not work.
Clearly, this can be done, since it is automatic when the device is an iPhone. I guess
I could create two views - one stacked and one split and choose based on a State variable
but that seems a bit crude.
Any guidance would be appreciated. Xcode 14 beta 6, iOS 16
This is a great idea and can be achieved by overriding the horizontalSizeClass in the environment depending on the environment value of dynamicTypeSize as follows:
struct NavigationSplitViewTest: View {
#Environment(\.dynamicTypeSize) var dynamicTypeSize
var body: some View {
ViewContainingSplitView()
.environment(\.horizontalSizeClass, dynamicTypeSize > .large ? .compact : .none)
}
}
I tested it by launching the app on iPad simulator and it was in 2 column, then switching to Settings to increase the type size by one notch then back to app and it had switched to single column. However when attempting to switch the size back I noticed the show/hide column button disappeared so I think we have some feedback to submit.
I still have not found an elegant way to do this, but my solution here does work.
Basically, I code for NavigationSplitView and for NavigationStack and change based on the
Environment(.dynamicTypeSize). Like this:
if dynamicTypeSize <= .xxLarge {
NavigationSplitView(columnVisibility: $columnVisibility) {
//all the code
} detail: {
//all the code
}
} else {
NavigationStack {
//all the code
}
}
For others, I was confused by the terms involved here. There is DynamicTypeSize, dynamic
fonts and Larger Accessibility Sizes. Dynamic fonts are those pre-built fonts that
support dynamic type out of the box - .title, .headline, .body etc. Dynamic type size is
the slider in settings that allows the user to scale the dynamic fonts to suit their
needs - all the dynamic fonts scale with the slider setting. Then on top of the slider
in settings for these pre-made fonts, is the option for Larger Accessibility sizes
which gives the user even bigger options.
My scheme above supports all of those intermingled options for both iPad and iPhone.
since the release of the new macOS Moterey operating system (12) my MacCatalyst application does not load some views at startup until I resize the window or change focus.
If I look at XCode's Debug View Hierarchy these views are not present.
If, on the other hand, I use the classic debug (while they are not shown) it turns out that they have the correct frame (origin and size), superviews and window.
To show them I have to resize the window (manually, using the mouse) or remove the focus from the app (for example by clicking on another window and then clicking the app window again).
Only after doing one of these two things are the views loaded.
Has anyone experienced the same behavior?
The application is developed in Swift only with UIKit and various Storyboards (without SwiftUI).
Thanks a lot to everyone.
I understand what happens.
If it can be useful to anyone ...
I use custom margins for my UIViewControllers. To calculate a margin, I use the minimum width of a scene as a variable.
I take this value in this way:
var minSceneWidth:CGFloat = 400
scenes.forEach { windowScene in
if let w = windowScene.sizeRestrictions?.minimumSize.width {
if minSceneWidth > w {
minSceneWidth = w
}
}
}
Since the latest version of macOS the value "minimumSize.width" seems to be also "0" and this is not good for the calculation of my margins.
Thank you all.
:-) Here comes a probably silly problem with a bit of a preamble sorry!
Long story short - I've been developing an app pulling my hair out due to a bug with the TabView in SwiftUI. I was overlaying the tabs with a ZLayer to add a funky big button in the middle - so when I was running into problems I thought this would be the issue... but this becomes irrelevant in a moment.
For simplicity I started a New project in XCode v11.6, build target iOS 13.6, Selected Tabbed App, created a very simple boilerplate SwiftUI content view with 2 tabs. (For clarity - I did not modify the default code at all). Runs perfectly on the simulator. Plug in my iPhone XS running iOS 13.6.1 (when I first encountered this problem I was on 13.5 so have updated iOS builds whilst this problem has occurred). Run the simple, non modified app on my phone. Loads up "First View", I tap the "Second" tab, nothing. No response at all. This is the same problem I am having in my more complicated app. Occasionally if I keep rebuilding. It will let me switch to "Second View" but then cannot switch back. The Tab Controller just seems to become non-responsive.
Now back to my more complicated app, on the first view there is a scroll view and there is a button with an attached actionSheet. If I pop open the action sheet, then dismiss it (regardless of just calling the .cancel() button or selecting an action), the Tab Controller works perfectly. There is another option which opens another sheet, again as soon as something has been overlayed, everything works as expected until the next app launch.
Tried resetting my MacBook, tried resetting my iPhone, tried uninstalling the build then rebuilding, cleaning the build folder, tried creating multiple projects with build targets iOS 13, 13.2, 13.5, 13.6. Problem seems to persist, but every time the simulator works perfectly.
So my questions here are: From my searching I can't find anyone with this problem. Is it just me really? Can anyone with XCode 11.6 and an iPhone XS please simply hit "New Project" -> "Tabbed App" and let me know if this works? (I'm almost wondering if there's a bug in XCode 11.6 when you create an app and everyone is either working on projects that were already created pre XCode 11.6 or already using the beta XCode... But really I am just out of ideas)
Also is there any deeper debugging one can do? Something like actually notifying me for every touch it receives and whether the App sandbox is getting the touch or the OS is (for some reason) keeping the tap gesture? I've never experienced something like this so I can't really see where to start debugging as I don't even know if the app is receiving the tap.
Or frankly - does anyone have any other ideas?
Just for clarity - ContentView looks like this: (Again it's straight from what XCode creates for a Tabbed App)
import SwiftUI
struct ContentView: View {
#State private var selection = 0
var body: some View {
TabView(selection: $selection){
Text("First View")
.font(.title)
.tabItem {
VStack {
Image("first")
Text("First")
}
}
.tag(0)
Text("Second View")
.font(.title)
.tabItem {
VStack {
Image("second")
Text("Second")
}
}
.tag(1)
}
}
}
struct ContentView_Previews: PreviewProvider {
static var previews: some View {
ContentView()
}
}
Thanks in advance and sorry for the long ramble - from a very sleepy dev at wits' end!
Apple has re-designed the share sheet that appears, which has now broken my UI tests.
I have attempted to record a new UI test through Xcode, but as soon as I tap on the dismiss button, the test terminates so I have not been able to capture the event.
Ultimately, I just want to know how I can access the gray 'X' shown with the arrow below:
I have just tested this with Xcode 13 and have found that the original answer no longer works. However, I am keeping it for posterity, or those using previous versions of Xcode.
Xcode 13
I have tested this with Xcode 13.0 and verified it works for iPhone and iPad:
let activityListView = app.otherElements.element(matching: .other,
identifier: "ActivityListView")
XCTAssertTrue(activityListView.waitForExistence(timeout: 2.0))
activityListView.buttons["Close"].tap()
Previous versions
After some trial and error, I was able to locate where my specific elements were with the following:
app.otherElements.element(boundBy: 1).buttons.element(boundBy: 0).tap()
Using app.otherElements.element(boundBy: 1) would identify the share sheet for me. I had attempted to locate it through accessibility identifiers, but I could not find one that worked, including previously valid ones used in iOS 12 and below.
Please note that based on the layout of your screen, the index value
may differ from what I am seeing.
Next, .buttons.element(boundBy: 0).tap() was used to locate the Close button. I again attempted to use identifiers, but could not find anything that represented the button.
When I attempted to discern additional information through the console while testing, I would always wind up crashing the test. This result was surprising, as I was able to query these elements with Xcode 10.
Ultimately, I would like to find working identifier values so that I can have something that works reliably across products, without the trial and error to find the share sheet's index value.
For iPad
The following will dismiss the popover for an iPad:
app.otherElements["PopoverDismissRegion"].tap()