Post not yet marked as solved
Light and dark and yes also Apples own applications. I kind of hope that Apple support read there forums. I'll file a report
Post not yet marked as solved
I am having reports from some users that they see my custom menuItem and some dont. I myself have it on one of my test devices XsMax and not on another iPhone 8.
Ok after going line by line the fix was to remove the cornerRadius I has set on the VStack. Didn't show that modifier in original post as I ddint think it was important. However posting here with full updated code.VStack{
//TF1
TextField("Duty", text: $dutyNumber)
.textFieldStyle(RoundedBorderTextFieldStyle())
.padding([.leading], 50)
.multilineTextAlignment(.center)
.keyboardType(.numberPad)
HStack{
//TF2
TextField("Start time", text: $dutyStartTime)
.textFieldStyle(RoundedBorderTextFieldStyle())
.padding([.leading], 50)
.multilineTextAlignment(.center)
.keyboardType(.numberPad)
//TF3
TextField("Finish time", text: $dutyFinishTime)
.textFieldStyle(RoundedBorderTextFieldStyle())
.padding([.leading], 50)
.multilineTextAlignment(.center)
.keyboardType(.numberPad)
}
}//.cornerRadius(4)
and if on device its not showing?
Post not yet marked as solved
The xcode beta download page has addedXcode 11 beta 5 is intended for use with iOS 13 beta 5. There are known incompatibilities when using SwiftUI on macOS Catalina beta 4. Update to macOS Catalina beta 5 when it becomes available.
The viewcontroller has a traitCollection and you can query its userInterfaceStyle.if traitCollection.userInterfaceStyle == .light {
//light mode
}
Post not yet marked as solved
would appear as of beta 11.3 the default is vertical scroll and setting the ,displayDirection to either .vertical or .horizontal now works. Only you have to set these properties before you set the pdfViews document. pdfView!.translatesAutoresizingMaskIntoConstraints = false
pdfView!.autoScales = true
pdfView!.usePageViewController(true, withViewOptions: [:])
pdfView!.displayDirection = .horizontal
pdfView!.document = PDFDocument(url: url)
Post not yet marked as solved
Depends on what you are selling. Without conext maybe "Apple pay" is route you want to go rather than IAPs.
Post not yet marked as solved
I have tried removing the print function and the memory still rises to 2GB. When I receive the .string call then the memory is fine. It’s also fine to keep the .string call though if I create new instance of the PDFDocument at every iteration of the loop. Problem though in doing so is that it’s far too slow. There seems to something about creating a PDFDocument outside a loop and referencing it inside.
Post not yet marked as solved
Did you try a text only document. Say with average 500 characters per page? It has to be down to the .string call that obviously depends on how many words you’re PDF has. no I had not modified the tap gesture signature.
Post not yet marked as solved
No. I checked that. Maybe is bug?
Post not yet marked as solved
Xcode Version 9.2 (9C40b)Mac OS High Sierra 10.13.2 (17C88)Swift 4 (reference to '[PDFPage string]' is how its shown in instruments. I guess because its bridged to NSString)error was also on the previous beta of both
Post not yet marked as solved
I am seeing the issue in instruments being the .string call on the PDFPage. My thinkig as to why its not crashing for you is you have images that doent effect the .string call. where as my pdf is all text
Post not yet marked as solved
could it be a bug as when I investigate through instruments its the[PDFPage string]that grows and grows in memory size. Rather than giving it back it increases
Post not yet marked as solved
in viewDidLoadlet tapPDF = UITapGestureRecognizer(target: self, action: #selector(self.scrapePDF(gesture:)))
self.documentView?.addGestureRecognizer(tapPDF)then as shown.
