<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Swift &#8211; Frankis Website</title>
	<atom:link href="https://fpposchmann.de/category/swift/feed/" rel="self" type="application/rss+xml" />
	<link>https://fpposchmann.de</link>
	<description>Consulting &#38; Software</description>
	<lastBuildDate>Mon, 27 Jan 2025 14:27:34 +0000</lastBuildDate>
	<language>de</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.7.2</generator>

<image>
	<url>https://fpposchmann.de/wp-content/uploads/2023/08/cropped-Bildschirmfoto-2023-08-07-um-14.23.35-32x32.png</url>
	<title>Swift &#8211; Frankis Website</title>
	<link>https://fpposchmann.de</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>Force a Save on a Document Based iOS App in SwiftUI</title>
		<link>https://fpposchmann.de/force-a-save-on-a-document-based-ios-app-in-swiftui/</link>
					<comments>https://fpposchmann.de/force-a-save-on-a-document-based-ios-app-in-swiftui/#respond</comments>
		
		<dc:creator><![CDATA[Frank-Peter Poschmann]]></dc:creator>
		<pubDate>Mon, 27 Jan 2025 14:27:34 +0000</pubDate>
				<category><![CDATA[Swift]]></category>
		<category><![CDATA[document]]></category>
		<category><![CDATA[iOS]]></category>
		<category><![CDATA[SwiftUI]]></category>
		<guid isPermaLink="false">https://fpposchmann.de/?p=914</guid>

					<description><![CDATA[Currently, I am developing a small document based App for iOS with SwiftUI. I was quite surprised to see that there is no obvious way to save the document’s contents to file after editing. In fact, the default behaviour was that nothing was saved at all after editing my document’s content. On macOS there is at least the possibility to update the change count to force a save later but that is not available on iOS SwiftUI.
Well, there is this hint on stackoverflow to register an undo at the UndoManager even if you do not use it. For some Views that worked for me; for others it didn’t. I was getting tired to spend hours in investigating why this was so. So I was looking for a way to save the document’s content explicitly. This is what I came up with.]]></description>
		
					<wfw:commentRss>https://fpposchmann.de/force-a-save-on-a-document-based-ios-app-in-swiftui/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>Restore Window Size on MacCatalyst Apps</title>
		<link>https://fpposchmann.de/restore-window-size-on-maccatalyst-apps/</link>
					<comments>https://fpposchmann.de/restore-window-size-on-maccatalyst-apps/#respond</comments>
		
		<dc:creator><![CDATA[Frank-Peter Poschmann]]></dc:creator>
		<pubDate>Wed, 06 Dec 2023 09:56:12 +0000</pubDate>
				<category><![CDATA[Swift]]></category>
		<category><![CDATA[MacCatalyst]]></category>
		<category><![CDATA[macOS]]></category>
		<category><![CDATA[SceneDelegate]]></category>
		<category><![CDATA[UserDefaults]]></category>
		<category><![CDATA[window]]></category>
		<guid isPermaLink="false">https://fpposchmann.de/?p=856</guid>

					<description><![CDATA[Sometimes its easier to just enable MacCatalyst on an iOS app to bring it to the Mac than to fiddle around with a dedicated Mac target or using the Mac version of SwiftUI. The drawback is that you don’t have access to AppKit but have to stick with UIKit / SwiftUI. So some quite useful features of AppKit are not available in MacCatalyst.

E.g. there is this nice AppKit construct to save and restore the window size and position between app launches:

controller.windowFrameAutosaveName = NSWindow.FrameAutosaveName("MyWindow")
But there is no equivalent in MacCatalyst since iOS apps don’t mess around with windows. In this post I’ll show how to achieve a similar behaviour in MacCatalyst.]]></description>
		
					<wfw:commentRss>https://fpposchmann.de/restore-window-size-on-maccatalyst-apps/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>An improved version of OutlinePicker</title>
		<link>https://fpposchmann.de/an-improved-version-of-outlinepicker/</link>
					<comments>https://fpposchmann.de/an-improved-version-of-outlinepicker/#respond</comments>
		
		<dc:creator><![CDATA[Frank-Peter Poschmann]]></dc:creator>
		<pubDate>Sat, 26 Aug 2023 13:38:58 +0000</pubDate>
				<category><![CDATA[Swift]]></category>
		<category><![CDATA[NodeOutlineGroup]]></category>
		<category><![CDATA[Outline]]></category>
		<category><![CDATA[Picker]]></category>
		<category><![CDATA[selection]]></category>
		<category><![CDATA[tree]]></category>
		<category><![CDATA[WithPopover]]></category>
		<guid isPermaLink="false">https://fpposchmann.de/?p=838</guid>

					<description><![CDATA[I’ve promised to present an improved version of the OutlinePicker shown in this post and here it is. What did I do?
1. The parameter list changed a little bit. Now there’s a special title for „No Selection“ and we do not need the isExpanded parameter anymore since we want to expand the nodes automatically according to the selection.
2. I’ve introduced the new array nodesToExpand. I'll come back to that a little bit later.
3. Instead of a sheet the selection view is presented as a popover (WithPopover from this post). Using that we do not need a close button anymore.
4. The NodeOutlineGroup from this post is used to accept the array of expanded nodes.
5. Instead of a Form I use a List here with a plain listStyle. That looks better in the popover view.
6. The „No Selection“ section is now separated from the list in a similar manner as a Divider would do it in a Picker view.]]></description>
		
					<wfw:commentRss>https://fpposchmann.de/an-improved-version-of-outlinepicker/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>An improved version of NodeOutlineGroup</title>
		<link>https://fpposchmann.de/an-improved-version-of-nodeoutlinegroup/</link>
					<comments>https://fpposchmann.de/an-improved-version-of-nodeoutlinegroup/#respond</comments>
		
		<dc:creator><![CDATA[Frank-Peter Poschmann]]></dc:creator>
		<pubDate>Mon, 14 Aug 2023 15:19:12 +0000</pubDate>
				<category><![CDATA[Swift]]></category>
		<category><![CDATA[NodeOutlineGroup]]></category>
		<category><![CDATA[Outline]]></category>
		<category><![CDATA[Picker]]></category>
		<guid isPermaLink="false">https://fpposchmann.de/?p=825</guid>

					<description><![CDATA[This is the second post of my little series about a fine-tuned version of my OutlinePicker. Today, I’d like to propose an improved version of the already presented NodeOutlineGroup. As stated here the NodeOutlineGroup gives you control whether the disclosure group should be collapsed or expanded on show up of the outline group. I want to use that for my hierarchical picker. But on start of my picker the pre-selected node might be deep in the tree instead of being one of the root nodes.

So, if I set up the picker with all nodes collapsed the pre-selected node would not be visible immediately and the user might search for it for quite a long time. On the other hand, if I expand all nodes it might be quite a big tree to display on startup. The ideal solution would be that all nodes are collapsed except to those ones which have the selected node as a child or grand child.]]></description>
		
					<wfw:commentRss>https://fpposchmann.de/an-improved-version-of-nodeoutlinegroup/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>WithPopover</title>
		<link>https://fpposchmann.de/withpopover/</link>
					<comments>https://fpposchmann.de/withpopover/#respond</comments>
		
		<dc:creator><![CDATA[Frank-Peter Poschmann]]></dc:creator>
		<pubDate>Mon, 07 Aug 2023 09:34:00 +0000</pubDate>
				<category><![CDATA[Swift]]></category>
		<category><![CDATA[popover]]></category>
		<category><![CDATA[View Controller]]></category>
		<guid isPermaLink="false">https://fpposchmann.de/?p=817</guid>

					<description><![CDATA[In this last post I‘ve proposed an OutlinePicker for SwiftUI. But, to be honest, I am not quite satisfied with this solution. The selection view appears as a sheet in contrast to the standard picker and its layout deserves some more fine tuning.

The problem with the standard popover modifier in SwiftUI is that it’s mutated to a sheet presentation on iPhones. I know, there is this new modifier presentationCompactAdaptation(horizontal:vertical:) but that’s only available since iOS16.4. In addition, I want to use a list in the popover and that’s collapsed to a tiny square if you do not specify a frame size. To make a long explanation short: I prefer to use the nice utility view „WithPopover“ for the presentation of my picker selection.]]></description>
		
					<wfw:commentRss>https://fpposchmann.de/withpopover/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>An Outline Picker for SwiftUI</title>
		<link>https://fpposchmann.de/an-outline-picker-for-swiftui/</link>
					<comments>https://fpposchmann.de/an-outline-picker-for-swiftui/#respond</comments>
		
		<dc:creator><![CDATA[Frank-Peter Poschmann]]></dc:creator>
		<pubDate>Fri, 28 Jul 2023 16:16:48 +0000</pubDate>
				<category><![CDATA[Swift]]></category>
		<category><![CDATA[Outline]]></category>
		<category><![CDATA[Picker]]></category>
		<category><![CDATA[selection]]></category>
		<category><![CDATA[tree]]></category>
		<guid isPermaLink="false">https://fpposchmann.de/?p=808</guid>

					<description><![CDATA[If you want to display an outline in SwiftUI you may use framework supplied OutlineGroup construct. That’s based on a nested tree of DisclosureGroup and is quite nice. But on appearance of the OutlineGroup all outlines are collapsed. Well, in one of my projects I wanted to display the outline all expanded on show up. No way to do that with OutlineGroup as far as I know. But then I found this nice variant (https://stackoverflow.com/questions/62832809/list-or-outlinegroup-expanded-by-default-in-swiftui) with a control of expansion:]]></description>
		
					<wfw:commentRss>https://fpposchmann.de/an-outline-picker-for-swiftui/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>Text Fields in Lists on macOS SwiftUI</title>
		<link>https://fpposchmann.de/text-fields-in-lists-on-macos-swiftui/</link>
					<comments>https://fpposchmann.de/text-fields-in-lists-on-macos-swiftui/#respond</comments>
		
		<dc:creator><![CDATA[Frank-Peter Poschmann]]></dc:creator>
		<pubDate>Fri, 21 Jul 2023 13:04:48 +0000</pubDate>
				<category><![CDATA[Swift]]></category>
		<category><![CDATA[alignment]]></category>
		<category><![CDATA[List]]></category>
		<category><![CDATA[macOS]]></category>
		<category><![CDATA[padding]]></category>
		<category><![CDATA[Text]]></category>
		<category><![CDATA[TextField]]></category>
		<guid isPermaLink="false">https://fpposchmann.de/?p=799</guid>

					<description><![CDATA[Today’s post is a bug report. I’ve sent a developer feed back to Apple already but got no response yet. I don’t know exactly when Apple introduced this bug But it may well be with the first release of macOS Ventura (13.0) and its still not fixed as of macOS 13.4.1.

At that time I’ve noticed that the text fields of one of my macOS Apps got an unintended left padding when included in a List.Here is a very simple text code to demonstrate the problem]]></description>
		
					<wfw:commentRss>https://fpposchmann.de/text-fields-in-lists-on-macos-swiftui/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>Missing Tiles in MKTileOverlayRenderer</title>
		<link>https://fpposchmann.de/missing-tiles-in-mktileoverlayrenderer/</link>
					<comments>https://fpposchmann.de/missing-tiles-in-mktileoverlayrenderer/#respond</comments>
		
		<dc:creator><![CDATA[Frank-Peter Poschmann]]></dc:creator>
		<pubDate>Fri, 09 Jun 2023 09:27:59 +0000</pubDate>
				<category><![CDATA[Swift]]></category>
		<category><![CDATA[Mapkit]]></category>
		<category><![CDATA[missing tiles]]></category>
		<category><![CDATA[MKTileOverlayRenderer]]></category>
		<category><![CDATA[pan gesture]]></category>
		<category><![CDATA[pinch gesture]]></category>
		<guid isPermaLink="false">https://fpposchmann.de/?p=794</guid>

					<description><![CDATA[Well, there is a bug in Apple’s MapKit since iOS 13.2, as the folks in developer community say: If you want to use non-Apple maps (e.g. OpenStreetMap®) occasionally tiles are not rendered although you supply the correct data in your sub-class of MKTileOverlayRenderer. There seems to be no obvious systematic but if you scroll around the map you’ll soon find missing tiles. There seems to be no real fix for that problem and your app will not be notified if that happens; the delegate method mapViewDidFinishRenderingMap(mapView:fullyRendered:) will always signal „fullyRendered“ although tiles may be missing.]]></description>
		
					<wfw:commentRss>https://fpposchmann.de/missing-tiles-in-mktileoverlayrenderer/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>.fileExporter and .fileImporter Won&#8217;t Work inside a Menu in SwiftUI</title>
		<link>https://fpposchmann.de/fileexporter-and-fileimporter-wont-work-inside-a-menu-in-swiftui/</link>
					<comments>https://fpposchmann.de/fileexporter-and-fileimporter-wont-work-inside-a-menu-in-swiftui/#respond</comments>
		
		<dc:creator><![CDATA[Frank-Peter Poschmann]]></dc:creator>
		<pubDate>Tue, 11 Apr 2023 08:57:53 +0000</pubDate>
				<category><![CDATA[Swift]]></category>
		<category><![CDATA[fileExporter]]></category>
		<category><![CDATA[fileImporter]]></category>
		<category><![CDATA[Menu]]></category>
		<category><![CDATA[SwiftUI]]></category>
		<guid isPermaLink="false">https://fpposchmann.de/?p=784</guid>

					<description><![CDATA[Recently, I noticed that the newly introduced fileImporter and fileExporter view modifiers in SwiftUI won't work inside a Menu view. It's not a big deal to put the file modifiers outside of the menu, but it took quite a while for me to pin down the problem.]]></description>
		
					<wfw:commentRss>https://fpposchmann.de/fileexporter-and-fileimporter-wont-work-inside-a-menu-in-swiftui/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>SwiftUI and the Problems of Timing</title>
		<link>https://fpposchmann.de/swiftui-and-the-problems-of-timing/</link>
					<comments>https://fpposchmann.de/swiftui-and-the-problems-of-timing/#respond</comments>
		
		<dc:creator><![CDATA[Frank-Peter Poschmann]]></dc:creator>
		<pubDate>Wed, 04 Jan 2023 10:02:48 +0000</pubDate>
				<category><![CDATA[Swift]]></category>
		<category><![CDATA[.onAppear]]></category>
		<category><![CDATA[delay]]></category>
		<category><![CDATA[focus]]></category>
		<category><![CDATA[SwiftUI]]></category>
		<category><![CDATA[timing]]></category>
		<guid isPermaLink="false">https://fpposchmann.de/?p=762</guid>

					<description><![CDATA[Well, SwiftUI is certainly a big improvement on building maintainable, robust and nice user interfaces on iOS and macOS compared to the old MVC architecture (Massive View Controller) and the NIB (Next Interface Builder). But it is mainly a declarative framework and from the application developer’s point of view its sometimes hard to anticipate what is really going on behind the scenes and especially when its going to happen. There are situations where the promised behaviour doesn’t take place and I’ve already struggled hours for hours to look for a workaround.

Especially the .onAppear modifier seems to be problematic. It looks as if the supplied closure will be executed too early sometimes and the statements inside do net have the desired effect.]]></description>
		
					<wfw:commentRss>https://fpposchmann.de/swiftui-and-the-problems-of-timing/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
	</channel>
</rss>
