Hi everyone, technodox10 here

This post is part of my ongoing rebuilding journey. Yesterday, I wrapped up reading a detailed comparison article on Kotlin, SwiftUI, and Flutter, and this write-up captures my key takeaways — especially around navigation, user input handling, platform integration, performance, and testing.

This is Part 2, focusing on how these frameworks behave in real-world app development rather than just theory.

SwiftUI

Navigation

SwiftUI handles navigation almost entirely through the NavigationLink modifier. Screen transitions, back navigation, and animations are abstracted away from the developer.

This makes development fast and clean, but it also means there is very little explicit control over navigation behavior. SwiftUI is a textbook example of heavy abstraction.

User Input

User interactions are handled using a minimal set of functions and property wrappers. The simplicity is powerful, but it can feel restrictive when building complex input flows.

Platform Integration

No external configuration is required. Everything is local because SwiftUI is purely native and built exclusively for iOS.

Optimization

SwiftUI automatically recalculates views when dependencies change. The framework manages recomputation efficiently without requiring manual optimization.

Runtime Performance

Excellent — but strictly limited to iOS.

Testing

Testing can be challenging. UI behavior is tightly coupled to the framework, making isolation and mocking harder.

Verdict

SwiftUI is extremely fast to code, provides instant UI updates, and offers clear compiler errors. However, it requires macOS and Xcode and is best suited for small to medium iOS-only applications.

Flutter

Navigation

Flutter gives developers full and explicit control. You define where to navigate, wait for results, specify result types, update state, and decide when and how to return. Nothing is hidden.

User Input

Controllers, input formatters, and setState drive most user interactions. While powerful, this introduces lifecycle complexity that must be carefully managed.

Platform Integration

Flutter relies heavily on third-party packages. Platform-specific features usually require plugins.

Optimization

Flutter recalculates UI whenever state changes, typically using getters. This behavior is predictable but may lead to unnecessary recomputation if not optimized properly.

Runtime Performance

Consistent across all supported platforms.

Testing

Widget testing is fairly solid, but testing controllers and state logic can be verbose and difficult.

Verdict

Flutter's hot reload accelerates development and encourages experimentation. However, strict controller lifecycles (registration, state management, and disposal) can slow development in larger applications.

Kotlin (Jetpack Compose / Multiplatform)

Navigation

The most verbose of the three — but also the clearest. Screens, routes, and navigation flows are explicitly defined. What happens before and after navigation is fully controlled by the developer.

User Input

Often driven by regex-based validation and structured state models. This adds precision but increases complexity.

Platform Integration

Cross-platform integration requires explicitly defined patterns and platform-specific hooks.

Optimization

derivedStateOf provides fine-grained control over recomputation, making optimization more intentional and predictable.

Runtime Performance

Consistent across platforms when implemented correctly.

Testing

Composable functions are easier to test because platform-specific code is isolated from UI logic.

Verdict

Kotlin has the steepest learning curve and takes the longest to set up, especially around navigation and syntax. However, it shines in large-scale, complex, cross-platform applications where long-term maintainability matters.

Final Thoughts on Frameworks

  • SwiftUI is ideal for fast development and smaller iOS-only apps.
  • Flutter excels at rapid prototyping and cross-platform delivery with a rich ecosystem.
  • Kotlin is best suited for structured, scalable systems where maintainability matters more than speed.

Choosing the right framework depends less on raw performance and more on app complexity, platform targets, and team workflow.

TryHackMe: SOC Analyst — Networking Basics

Understanding networking fundamentals is critical for anyone aiming to become a SOC Analyst. Below are key concepts from the TryHackMe networking module, covering everything from the origins of the internet to modern network communication.

A Brief History of Networking

1960 — ARPANET The first computer network, designed to connect research institutions.

1989 — World Wide Web Introduced by Tim Berners-Lee to store and share information over the internet.

Public vs Private Networks

  • Public Network: Connects private networks to the internet.
  • Private Network: Smaller, isolated networks (home or office).

Device Identification in a Network

Devices are identified using:

IP Address

  • Temporary
  • Changes over time
  • Cannot be shared simultaneously

IP Protocols

IPv4

  • 32-bit addressing
  • Example: 192.168.1.1
  • Supports ²³² addresses

IPv6

  • 128-bit addressing
  • Supports ²¹²⁸ addresses

MAC Address (Media Access Control)

  • Physical address embedded in the NIC
  • Format: AA:BB:CC:DD:EE:FF
  • First half: Manufacturer ID
  • Second half: Unique identifier

Ping and ICMP

ping tests connectivity using ICMP Echo Request and Reply.

Example:

ping -c 4 8.8.8.8

Shows packet loss and round-trip time (RTT).

Network Topologies

  • Ring: One failure breaks the network
  • Bus: Cheap but inefficient under load
  • Star: Expensive but scalable and reliable

Switches and Routers

  • Switch: Routes traffic within a network
  • Router: Connects multiple networks

Subnetting Basics

  • Network Address
  • Host Address
  • Default Gateway
  • Subnet Mask (32-bit)

ARP

Maps IP addresses to MAC addresses using ARP requests and replies.

DHCP

Automatically assigns IP addresses:

  1. Discover
  2. Offer
  3. Request
  4. Acknowledge

OSI Model (Up to Layer 3)

  • Layer 1: Physical (hardware)
  • Layer 2: Data Link (MAC)
  • Layer 3: Network (IP & routing)

At this point, my brain was fried, so I paused here 😅.

Bug Hunting Update

I couldn't continue with my original bug bounty program due to KYC issues. I switched to another platform where setup went smoothly.

I spent time understanding the rules and scope and will start hunting tomorrow. The key relief was that no KYC was required, allowing me to focus purely on security research.

API Security Toolkit — Coding Progress

Today, I implemented authentication checks in my API Security Toolkit.

The logic tests an endpoint in three scenarios:

  1. No authorization token
  2. Fake authorization token
  3. Legitimate authorization token

Using the requests library:

requests.get(url)

To add headers:

headers = {
    "Authorization": "Bearer 12345677"
}
r = requests.get(url, headers=headers)

This marks the foundation of my toolkit. More to come.

Well that's all, folks,

Until next time,

This is technodox10 signing off

Bye