DEV Community: nooraja

Building a Full-Stack iOS Stock App on $4/Month: UIKit, Go, Supabase, and AI

nooraja — Thu, 10 Sep 2026 17:22:52 +0000

Building a Full-Stack iOS Stock App on IDR 60K/Month

TradingFlow began as an iOS app for US stock search, watchlists, details, charts, and news. Making it usable beyond a development machine eventually required a complete path from UIKit to the database.

Architecture

UIKit app
  ├── Supabase Auth → user session in Keychain
  └── Bearer token over HTTPS
          ↓
       Caddy
          ↓
   Go REST API (net/http)
     ├── Finnhub
     ├── Yahoo / yfinance-go
     └── Supabase Postgres + RLS

Provider secrets stay on the server. The app contains publishable configuration and the user session only. The example deliberately excludes credentials, UUIDs, deployment addresses, and personal email.

The iOS layer

The main UI uses UIKit, Auto Layout, Dynamic Type, SF Symbols, and a native tab bar. Networking uses URLSession and async/await. Search is debounced by 350 ms and cancels the previous task so an older response cannot overwrite a newer query.

Tokens are stored in Keychain. After a 401, the client refreshes the session once and retries. If that still fails, it removes the session and returns to sign-in. UserDefaults is used only for an email address the user explicitly asks the app to remember.

Swift Charts is the only SwiftUI surface:

let host = UIHostingController(rootView: PriceChart(chart: response.data))
addChild(host)
container.addSubview(host.view)
host.didMove(toParent: self)

This keeps the screen architecture in UIKit while using Apple’s native charting framework. The trade-off is managing the child-controller lifecycle and the state boundary.

The Go layer

The API uses the standard net/http package. I kept dependencies small and made important behavior explicit:

request timeouts and cancellation;
symbol and query validation;
a stable response envelope;
size-bounded in-memory caching;
local provider rate limiting and a concurrency gate;
error mapping that does not leak upstream responses;
authentication middleware and request IDs.

The backend exposes market overview, search, watchlist, detail, chart, statistics, analyst consensus, and news endpoints. GET /health is public, while product endpoints require a valid access token.

Go provides a small binary and straightforward deployment. The cost of that simplicity is visible plumbing: no framework silently chooses the behavior for us.

Market-data providers are imperfect

Finnhub handles quotes, profiles, search, market state, analyst data, and news. Yahoo through yfinance-go fills historical charts, reference quotes, indices, and selected statistics.

I learned to design responses around upstream reality: fields may be null; requests may receive 429; units and timestamps differ; one provider can succeed while another fails; charts can be rejected; and data may be delayed.

Responses therefore include source, mode, fetch time, and cache metadata. The UI supports loading, empty, partial, rate-limit, and retry states. It never silently falls back to fabricated numbers.

Auth, Postgres, and RLS

Supabase Auth issues the user access token. Go verifies it, derives identity from the verified session rather than request input, and accesses the watchlist table with the same user token.

The watchlist primary key is (user_id, symbol). RLS filters SELECT/INSERT/DELETE by the active user. A transaction lock keeps the 100-item cap atomic under concurrent inserts.

Supabase accelerates development, but RLS is not a security checkbox. Policies need tests with at least two accounts to prove isolation.

Deployment and budget

A multi-stage Docker build produces a non-root, read-only container. Docker Compose runs the API and Caddy; only Caddy exposes public ports and handles HTTPS. The VPS has 2 vCPU, 2 GB RAM, 40 GB storage, and runs in Singapore.

The budget I count is:

Item	Incremental cost
VPS	IDR 60,000/month
Supabase	IDR 0 while within the current free access/tier
Market-data providers	IDR 0 for the current experiment
Stitch + Figma	IDR 0 incremental in this workflow
Experimental hostname + TLS	IDR 0

The baseline is IDR 60,000 per month. It excludes an existing ChatGPT/Codex subscription, Apple Developer Program membership, a custom domain, taxes, and overages. A free tier is a limit, not a guarantee of permanent zero cost.

Where ChatGPT/Codex helped

I used AI as a pair programmer to map designs to API contracts, scaffold code, create tests, audit security, and maintain deployment documentation. My loop is:

provide scope, constraints, and source files;
request small, inspectable changes;
read the diff and compare it with the real contract;
run Swift type checks/API contract checks plus go test -race ./... and go vet ./...;
correct unsupported assumptions or labels.

AI has suggested technologies that the project does not use. That is a useful reminder: convincing output is not necessarily correct. Never place secrets in prompts, never paste production configuration into an article, and never skip review because the code compiles.

Trade-offs at a glance

Technology	Advantage	Cost
UIKit	Precise and mature	Verbose
Swift Charts bridge	Native and dependency-free	UIKit–SwiftUI boundary
Go `net/http`	Small and explicit	Manual plumbing
Supabase	Fast Auth + Postgres + RLS	Policy complexity and vendor coupling
Finnhub + Yahoo	Useful coverage	Limits, partial data, licensing
VPS + Caddy	Low cost and high control	Self-managed operations
ChatGPT/Codex	Faster iteration	Hallucinations and risk without review

Mobile full-stack is not a new title for me. It is the ability to follow one user action—such as tapping Save—through UI, token, network, handler, database policy, response, and failure state, then prove that the entire path is safe and understandable.

Make Your UICollectionView Cells Resize Themselves in iOS 16 (No reloadData())

nooraja — Wed, 09 Sep 2026 02:08:04 +0000

A collection view cell often needs to change height after it is already onscreen: an expandable description, a validation message, or content returned by an asynchronous request are familiar examples.

The instinctive solution is usually reloadData(), reloadItems(at:), or collectionViewLayout.invalidateLayout(). Those APIs still have their place for data and layout changes, but using them solely to re-measure one self-sizing cell is unnecessarily broad.

Since iOS 16, UICollectionView and UITableView expose selfSizingInvalidation. The property tells UIKit how to react when a self-sizing cell needs a new intrinsic size.

The three modes

Mode	Use it when
`.disabled`	You want UIKit to skip self-sizing invalidation.
`.enabled`	Your cell will explicitly call `invalidateIntrinsicContentSize()`.
`.enabledIncludingConstraints`	You also want UIKit to invalidate automatically after a constraint change inside the cell’s `contentView`.

For an expand/collapse interaction, I prefer .enabled: the cell is explicit about the moment its visible content changes.

collectionView.selfSizingInvalidation = .enabled

UICollectionViewCompositionalLayout.list(using:) provides an excellent self-sizing list layout, so the demo does not need a custom layout subclass or a manual sizeForItemAt implementation.

Complete example

Create a UIKit view controller, set the deployment target to iOS 16 or later, and add this file. The code uses a list-style compositional layout, an Auto Layout-backed cell, and an expandable detail label.

import UIKit

@available(iOS 16.0, *)
final class DynamicSizeViewController: UIViewController {
    fileprivate struct Article: Hashable {
        let id = UUID()
        let title: String
        let body: String
        var isExpanded = false
    }

    private var articles = [
        Article(title: "What is selfSizingInvalidation?", body: "An iOS 16 UIKit API that re-measures an Auto Layout-backed cell without reloading the entire collection view."),
        Article(title: "When is it useful?", body: "Use it when a user expands a description, asynchronous content arrives, or a view inside the cell changes height.")
    ]

    private lazy var collectionView: UICollectionView = {
        var configuration = UICollectionLayoutListConfiguration(appearance: .insetGrouped)
        configuration.showsSeparators = false

        let view = UICollectionView(
            frame: .zero,
            collectionViewLayout: UICollectionViewCompositionalLayout.list(using: configuration)
        )
        view.translatesAutoresizingMaskIntoConstraints = false
        view.backgroundColor = .systemGroupedBackground
        view.dataSource = self
        view.register(ExpandableCell.self, forCellWithReuseIdentifier: ExpandableCell.reuseIdentifier)
        view.selfSizingInvalidation = .enabled
        return view
    }()

    override func viewDidLoad() {
        super.viewDidLoad()
        view.addSubview(collectionView)
        NSLayoutConstraint.activate([
            collectionView.topAnchor.constraint(equalTo: view.safeAreaLayoutGuide.topAnchor),
            collectionView.leadingAnchor.constraint(equalTo: view.leadingAnchor),
            collectionView.trailingAnchor.constraint(equalTo: view.trailingAnchor),
            collectionView.bottomAnchor.constraint(equalTo: view.bottomAnchor)
        ])
    }
}

@available(iOS 16.0, *)
extension DynamicSizeViewController: UICollectionViewDataSource {
    func collectionView(_ collectionView: UICollectionView, numberOfItemsInSection section: Int) -> Int {
        articles.count
    }

    func collectionView(_ collectionView: UICollectionView, cellForItemAt indexPath: IndexPath) -> UICollectionViewCell {
        let cell = collectionView.dequeueReusableCell(
            withReuseIdentifier: ExpandableCell.reuseIdentifier,
            for: indexPath
        ) as! ExpandableCell

        let article = articles[indexPath.item]
        cell.configure(with: article) { [weak self] isExpanded in
            guard let self,
                  let index = self.articles.firstIndex(where: { $0.id == article.id }) else { return }
            self.articles[index].isExpanded = isExpanded
        }
        return cell
    }
}

@available(iOS 16.0, *)
private final class ExpandableCell: UICollectionViewCell {
    static let reuseIdentifier = "ExpandableCell"

    private let titleLabel = UILabel()
    private let bodyLabel = UILabel()
    private let toggleButton = UIButton(type: .system)
    private var isExpanded = false
    private var onToggle: ((Bool) -> Void)?

    override init(frame: CGRect) {
        super.init(frame: frame)

        titleLabel.font = .preferredFont(forTextStyle: .headline)
        titleLabel.numberOfLines = 0
        bodyLabel.font = .preferredFont(forTextStyle: .body)
        bodyLabel.numberOfLines = 0
        bodyLabel.textColor = .secondaryLabel
        toggleButton.addTarget(self, action: #selector(toggle), for: .touchUpInside)

        let stack = UIStackView(arrangedSubviews: [titleLabel, bodyLabel, toggleButton])
        stack.axis = .vertical
        stack.spacing = 12
        stack.translatesAutoresizingMaskIntoConstraints = false
        contentView.addSubview(stack)

        NSLayoutConstraint.activate([
            stack.topAnchor.constraint(equalTo: contentView.layoutMarginsGuide.topAnchor),
            stack.leadingAnchor.constraint(equalTo: contentView.layoutMarginsGuide.leadingAnchor),
            stack.trailingAnchor.constraint(equalTo: contentView.layoutMarginsGuide.trailingAnchor),
            stack.bottomAnchor.constraint(equalTo: contentView.layoutMarginsGuide.bottomAnchor)
        ])
    }

    required init?(coder: NSCoder) { nil }

    func configure(with article: DynamicSizeViewController.Article, onToggle: @escaping (Bool) -> Void) {
        titleLabel.text = article.title
        bodyLabel.text = article.body
        isExpanded = article.isExpanded
        self.onToggle = onToggle
        render()
    }

    @objc private func toggle() {
        isExpanded.toggle()
        render()
        onToggle?(isExpanded)
    }

    private func render() {
        bodyLabel.isHidden = !isExpanded
        toggleButton.setTitle(isExpanded ? "Show less" : "Read more", for: .normal)
        invalidateIntrinsicContentSize()
    }
}

The key line is the last one in render():

invalidateIntrinsicContentSize()

With .enabled, that call tells UIKit to measure the cell again. Auto Layout calculates the new height from the stack view and its visible arranged subviews, then the collection view updates the cell. Notice what is intentionally absent:

// No reloadData()
// No reloadItems(at:)
// No collectionView.collectionViewLayout.invalidateLayout()

When should I use `.enabledIncludingConstraints`?

Use it when the change itself is a constraint mutation inside contentView—for example, activating a height constraint after an image loads. UIKit will automatically call invalidateIntrinsicContentSize() in that scenario.

collectionView.selfSizingInvalidation = .enabledIncludingConstraints

It still supports an explicit invalidateIntrinsicContentSize() call. That is useful when the change is semantic content (for example, text or visibility) and you want the re-measurement point to be obvious in the code.

Two practical rules

Keep contentView fully constrained. The list can only infer height correctly when the cell has an unbroken Auto Layout chain from top to bottom.
Keep UI state in the data model. selfSizingInvalidation recalculates size; it does not preserve state during cell reuse. The example saves isExpanded back to articles for that reason.

For a visual transition, wrap the property change in UIView.animate(withDuration:). Avoid jumping to a collection-view reload unless the underlying item set or item data genuinely requires one.

References

Text Selection in SwiftUI TextEditor Is Still Harder Than It Should Be

nooraja — Thu, 27 Aug 2026 13:34:25 +0000

TextEditor looks wonderfully simple:

TextEditor(text: $note)

People can type multiple lines, move the caret, long press, select text, and copy or paste. For an ordinary notes field, that is excellent.

The trouble begins when the app itself needs to understand that selection.

What if a Bold toolbar action should activate only when text is selected? What if a template must be inserted at the caret? Or if suggestions depend on the word the user has highlighted?

At that point, SwiftUI's TextEditor can feel more difficult than long-established UIKit controls.

Selection UI is not selection state

First, an important distinction: users can select text directly in TextEditor. iOS supplies the familiar caret, selection handles, and system Copy/Paste menu.

The historical gap was accessing the state of that selection from SwiftUI. The basic TextEditor(text:) API binds only the editor's contents to a String:

@State private var note = "Select part of this text."

TextEditor(text: $note)

We know the value of note, but not whether the user is at character 5 or has selected characters 5 through 20. That small distinction matters enormously to a feature-rich editor.

The good news: `TextSelection` in iOS 18

SwiftUI now has an official answer: TextSelection and the TextEditor(text:selection:) initializer in iOS 18.

import SwiftUI

struct NoteEditor: View {
    @State private var text = "Select part of this text."
    @State private var selection: TextSelection?

    var body: some View {
        TextEditor(text: $text, selection: $selection)
            .frame(minHeight: 180)
    }
}

TextSelection can represent an insertion point (the caret) or a range of text. An app can therefore respond to a user's selection without inspecting the UIKit view behind SwiftUI.

This is meaningful progress, but it has two practical consequences:

The API requires iOS 18 or later.
It does not remove the need for UIKit when an editor is highly customized or must support older iOS versions.

Why UIKit feels more direct

UIKit has had a mature text-input model for a long time through UITextInput. Both UITextField and UITextView expose selectedTextRange; for multiline editing, UITextView also exposes selectedRange as an NSRange.

Here is how to select all text in a UITextField:

let field = UITextField()
field.text = "INV-2026-0817"

if let range = field.textRange(
    from: field.beginningOfDocument,
    to: field.endOfDocument
) {
    field.selectedTextRange = range
}

In UIKit, selection has long been part of the public API surface. You can read the active range, change it, and receive notifications when it changes.

One important note: the correct UIKit counterpart to a multiline TextEditor is UITextView, not UITextField. UITextField is still a useful example because both controls use the same UITextInput model.

Need	SwiftUI `TextEditor`	UIKit
User selection with native iOS UI	Yes	Yes
Bind the text value	`Binding<String>`	`text` plus target/delegate
Read or change selection in code	`TextSelection` on iOS 18+	`selectedTextRange` / `selectedRange`
Multiline editing	Yes	`UITextView`
Support selection state on older iOS	Needs another strategy	Long-standing API support
Highly customized input behavior	More limited	Broader delegate and `UITextInput` control

The fallback: wrap `UITextView`

If your deployment target includes iOS 17 or earlier and selection is a product requirement, the straightforward fallback is a UITextView in UIViewRepresentable.

struct UIKitEditor: UIViewRepresentable {
    @Binding var text: String
    @Binding var selectedRange: NSRange

    func makeUIView(context: Context) -> UITextView {
        let view = UITextView()
        view.delegate = context.coordinator
        return view
    }

    func updateUIView(_ view: UITextView, context: Context) {
        if view.text != text { view.text = text }
        if view.selectedRange != selectedRange {
            view.selectedRange = selectedRange
        }
    }

    func makeCoordinator() -> Coordinator { Coordinator(self) }

    final class Coordinator: NSObject, UITextViewDelegate {
        var parent: UIKitEditor
        init(_ parent: UIKitEditor) { self.parent = parent }

        func textViewDidChange(_ textView: UITextView) {
            parent.text = textView.text
        }

        func textViewDidChangeSelection(_ textView: UITextView) {
            parent.selectedRange = textView.selectedRange
        }
    }
}

The wrapper delivers the required control, but it comes with cost: two-way synchronization, focus management, accessibility, Dynamic Type, and range validation whenever text changes.

One detail is easy to miss: NSRange uses UTF-16 offsets, not Swift Character counts. Emoji and combined characters can make index conversion a source of bugs. Do not assume that NSRange(location: 2, length: 1) simply means “the third character.”

A gap that is still noticeable after SwiftUI's 2019 debut

Apple introduced SwiftUI in 2019 and has clearly continued to invest in it. TextSelection in iOS 18 shows that Apple recognizes modern editor requirements.

Still, the gap is not entirely closed:

The modern selection-state API arrived only in iOS 18, so it does not solve the problem for apps that support older systems.
Developers of feature-rich editors still often need UIKit's deeper capabilities.
Bridging to UITextView increases the size and complexity of a codebase for behavior that has long been fundamental to UIKit text input.

The fair criticism is not “SwiftUI cannot select text.” Users can select text in TextEditor. The more precise criticism is this: observing and controlling selection from SwiftUI arrived late, and it still does not fully replace UIKit's depth.

Practical recommendation

Use TextEditor(text:) for a simple note editor.
Use TextEditor(text:selection:) when iOS 18 is your minimum target and the app needs selection state.
Use a UITextView wrapper when you must support older iOS versions or need a highly customized editor.
Do not use UITextField for multiline content; use UITextView.

SwiftUI makes many things more elegant. For advanced text editing, however, UIKit remains an important escape hatch—which feels a little ironic after years of Apple investment in SwiftUI.

References

SwiftUI Text Selection vs UITextView: the compatibility gap Apple left behind

nooraja — Thu, 27 Aug 2026 06:25:23 +0000

Text selection is a small feature with a large usability impact. Users often need to copy error messages, transaction IDs, URLs, log output, addresses, or a single sentence from a longer block of text.

SwiftUI makes enabling it delightfully small:

Text("Request failed: 401 Unauthorized")
    .textSelection(.enabled)

However, this modifier has a behaviour change that matters a lot for compatibility. The same source code does not deliver the same selection experience on every supported iOS release.

The short version

Platform / version	What `.textSelection(.enabled)` does
macOS 12+	Lets people select a text range with normal pointer and keyboard conventions.
iOS / iPadOS 15 through 26	Long press exposes a system menu that acts on the whole `Text` view. No native range handles for selecting only part of that `Text`.
iOS / iPadOS 27+	Long press shows selection highlight and handles, enabling range selection.

Apple documents this distinction explicitly. The modifier has been available since iOS 15, yet the familiar partial-selection interaction only arrives in iOS 27. That is a frustrating gap for something as basic as selecting two words in a paragraph. Come on, Apple: SwiftUI should not force a UIKit escape hatch for a fundamental text interaction after so many years.

The iOS 27 row reflects Apple’s current documentation. Test it on the target OS and Xcode you are shipping with; do not infer the behaviour just from the modifier compiling.

What SwiftUI gets right

One clear, composable API

VStack(alignment: .leading) {
    Text("Build failed")
        .font(.headline)
    Text(logOutput)
        .font(.system(.body, design: .monospaced))
}
.textSelection(.enabled)

Applying the modifier to a container can enable selection for the contained Text views. That is clean, discoverable SwiftUI code with no subclassing or delegate plumbing.

Great for whole-value copying

On iOS 15–26, the behaviour is still useful when the entire value is what users want: a UUID, an email address, an API key displayed safely, an error message, or an IP address. Apple’s Human Interface Guidelines specifically calls out useful labels such as error messages, locations, and IP addresses as candidates for copyability.

Native accessibility and platform conventions

SwiftUI hands the interaction to the system, which is generally a good default. On macOS in particular, .textSelection(.enabled) feels natural immediately.

Where SwiftUI `Text` falls short

1. Partial selection on iOS was missing until iOS 27

For a paragraph, log, or legal text, users commonly want only a phrase. On iOS 26 and earlier, SwiftUI treats a selectable Text as a whole-value copy target. There are no selection handles to adjust the range.

This is the central limitation. The modifier can make an app look like it supports selection while delivering a less capable experience on most deployed versions.

2. No selection inside `Button`

Apple documents that Button views do not support text selection. If a piece of text needs both a tap action and copyable text, redesign the interaction or use a separate control instead of expecting .textSelection to solve both jobs.

3. Limited control over the interaction

Text exposes an opt-in switch, not a text-engine configuration surface. If the product needs precise selection behaviour, custom menus, programmatic ranges, selection-state observation, or highly custom rich-text interaction, SwiftUI’s simple modifier can become too restrictive.

SwiftUI `Text` versus UIKit `UITextView`

The useful UIKit comparison is UITextView, not UILabel.

UITextView is a full text component. For read-only selectable content, configure it with isEditable = false and isSelectable = true. It has long supplied UIKit’s standard range-selection UI: selection highlight, drag handles, the loupe in long text, and copy actions.

Unlike Text, it is imperative and heavier. In SwiftUI, it needs a UIViewRepresentable bridge; its container, scrolling, sizing, and accessibility need careful integration. But when the requirement is “select part of this text” on iOS 15–26, it is the reliable native answer.

UILabel is worth mentioning only to avoid a common misconception: it is a display view and has no native selectable-text API. Do not use it as the selection fallback.

Capability	SwiftUI `Text`	UIKit `UITextView` (read-only)
Display static text	Excellent	Good, but heavier
Enable copy with a small API	Yes: `.textSelection(.enabled)`	Yes: configure properties
Range selection on iOS 26 and earlier	No, whole `Text` action only	Yes
Rich attributed content	Improving, but intentionally higher-level	Strong interaction + display support
Selection handles / loupe / standard editing mechanics	iOS 27+ for `Text` ranges	Yes
Custom selection interaction	Limited	Broad UIKit control; can go further with `UITextInteraction`
SwiftUI layout ergonomics	Excellent	Requires a wrapper

So the relevant decision is Text vs a read-only UITextView.

The UIKit fallback for older iOS versions

When range selection is a requirement before iOS 27, bridge a non-editable UITextView into SwiftUI:

import SwiftUI
import UIKit

struct SelectableTextView: UIViewRepresentable {
    let attributedText: NSAttributedString

    func makeUIView(context: Context) -> UITextView {
        let textView = UITextView()
        textView.isEditable = false
        textView.isSelectable = true
        textView.isScrollEnabled = false
        textView.backgroundColor = .clear
        textView.textContainerInset = .zero
        textView.textContainer.lineFragmentPadding = 0
        textView.adjustsFontForContentSizeCategory = true
        return textView
    }

    func updateUIView(_ textView: UITextView, context: Context) {
        textView.attributedText = attributedText
    }
}

Usage:

SelectableTextView(
    attributedText: NSAttributedString(
        string: longReleaseNote,
        attributes: [
            .font: UIFont.preferredFont(forTextStyle: .body),
            .foregroundColor: UIColor.label
        ]
    )
)

UITextView has more layout and accessibility details to verify than Text: Dynamic Type, text-container sizing, links, scrolling, ScrollView nesting, and content compression. It is not as elegant, but it uses the mature UIKit text system that already supplies standard selection UI for native text views.

For custom UIKit text components, UITextInteraction can provide the system’s non-editable selection behaviour, including the selection UI and gestures, as long as the custom view implements the required text-input machinery.

A pragmatic compatibility strategy

Choose the implementation based on the user task, not ideology:

if #available(iOS 27.0, *) {
    Text(articleBody)
        .textSelection(.enabled)
} else {
    SelectableTextView(
        attributedText: NSAttributedString(string: articleBody)
    )
}

Use this strategy only when partial selection is a real requirement. A UITextView bridge is unnecessary complexity for a one-line order ID where copying the entire value is correct.

Decision guide

Short, whole-value content: use Text with .textSelection(.enabled).
macOS app: native SwiftUI text selection is usually the simplest choice.
Long text where iOS 15–26 users must select a phrase: use a read-only UITextView wrapper.
Custom interaction or selection menus: start from UIKit; evaluate UITextInteraction if UITextView is not enough.
Text inside a button: separate the button action from the copyable text.

Final thought

SwiftUI’s API is wonderfully small, and that is exactly why many teams reach for it first. But simplicity is only a win when the behaviour meets the platform expectation. Until iOS 27, .textSelection(.enabled) on iPhone is closer to “make this whole value copyable” than “let the user select text.”

That distinction belongs in product requirements, compatibility testing, and code review. Apple has finally closed the gap in the documented iOS 27 behaviour—but it took far too long for such a fundamental capability.

DEV Community: nooraja

Building a Full-Stack iOS Stock App on $4/Month: UIKit, Go, Supabase, and AI

Building a Full-Stack iOS Stock App on IDR 60K/Month

Architecture

The iOS layer

The Go layer

Market-data providers are imperfect

Auth, Postgres, and RLS

Deployment and budget

Where ChatGPT/Codex helped

Trade-offs at a glance

Make Your UICollectionView Cells Resize Themselves in iOS 16 (No reloadData())

The three modes

Complete example

When should I use .enabledIncludingConstraints?

Two practical rules

References

Text Selection in SwiftUI TextEditor Is Still Harder Than It Should Be

Selection UI is not selection state

The good news: TextSelection in iOS 18

Why UIKit feels more direct

The fallback: wrap UITextView

A gap that is still noticeable after SwiftUI's 2019 debut

Practical recommendation

References

SwiftUI Text Selection vs UITextView: the compatibility gap Apple left behind

The short version

What SwiftUI gets right

One clear, composable API

Great for whole-value copying

Native accessibility and platform conventions

Where SwiftUI Text falls short

1. Partial selection on iOS was missing until iOS 27

2. No selection inside Button

3. Limited control over the interaction

SwiftUI Text versus UIKit UITextView

The UIKit fallback for older iOS versions

A pragmatic compatibility strategy

Decision guide

Final thought

Sources

When should I use `.enabledIncludingConstraints`?

The good news: `TextSelection` in iOS 18

The fallback: wrap `UITextView`

Where SwiftUI `Text` falls short

2. No selection inside `Button`

SwiftUI `Text` versus UIKit `UITextView`