Open Source Swift Networking Software

Bagel is a little native iOS network debugger. It's not a proxy debugger so you don't have to mess around with certificates, proxy settings etc. As long as your iOS devices and your Mac are in the same network, you can view the network traffic of your apps separated by the devices or simulators. Most basic usage is to start Bagel iOS before any network operation. Since Bagel exposes every request info to the public it would be better if you disable it for the store versions. By default, Bagel gets your project name and device information. The desktop client uses this information to separate projects and devices. You can configure these if you wish. Bagel framework communicates with the desktop client by using Bonjour protocol. You can also configure these Netservice parameters.

Connectivity is a wrapper for Apple's Reachability providing a reliable measure of whether Internet connectivity is available where Reachability alone can only indicate whether an interface is available that might allow a connection. Connectivity's objective is to solve the captive portal problem whereby an iOS device is connected to a WiFi network lacking Internet connectivity. Such situations are commonplace and may occur for example when connecting to a public WiFi network which requires the user to register before use. Connectivity can detect such situations enabling you to react accordingly.

There is always this friction when it comes to debugging native apps: you can’t inspect anything that happens behind the scenes unless you use special tools, not even network requests. That’s not the case on the web with tools like Safari Web Inspector. I wanted to bring something similar to native apps. What is Pulse? It’s a persistent logger with a network inspector, but not just a tool. It’s also a framework. PulseCore.framework (iOS, macOS, watchOS, tvOS) provides a logger itself and a network proxy for automatically capturing network requests. PulseUI.framework (iOS, macOS, watchOS, tvOS) containing all the UI components you’ll see on the screenshots. Document-based Pulse apps (iOS, macOS) to view logs shared from other devices. As a developer, you integrate the frameworks into your app and configure them to capture logs and network traffic. You then add a way to display a Pulse console to view logs right on the device.

SwiftNIO is a cross-platform asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. Low-level protocol implementations are often a collection of ChannelHandlers that implement a protocol but still require the user to have a good understanding of SwiftNIO. Often, low-level protocol implementations will then be wrapped in high-level libraries with a nicer, more user-friendly API. High-level implementations are usually libraries that come with an API that doesn't expose SwiftNIO's ChannelPipeline and can therefore be used with very little (or no) SwiftNIO-specific knowledge. The implementations listed below do still do all of their I/O in SwiftNIO and integrate really well with the SwiftNIO ecosystem. SwiftNIO aims to support all of the platforms where Swift is supported. Currently, it is developed and tested on macOS and Linux.

swift-url-routing is a bidirectional router with more type safety and less fuss. This library is built with Parsing. ​

Using the iOS SDK for FreeRTOS Bluetooth Devices, you can create mobile applications that do the following. Scan for and connect to nearby BLE devices running FreeRTOS. Provision Wi-Fi networks for a BLE device running FreeRTOS. Act as a proxy for transmitting MQTT messages between a device running FreeRTOS and the AWS IoT cloud.

A free, fully open-source application firewall for macOS 10.13 High Sierra and later. Allows real-time monitoring of network connections being made by applications, and blocking/allowing of these per app by user. Supports use of hostname lists (Energized Blu etc) to block known tracker and advertising domains for all apps. Also allows blocking of all network connections for specified apps, blocking of all connections except for specified whitelisted connections, use of pre-configured lists of connections per app to allow/block etc.

You’re a smart developer. You probably use Alamofire to abstract away access to URLSession and all those nasty details you don’t really care about. But then, like lots of smart developers, you write ad hoc network abstraction layers. They are probably called APIManager or NetworkModel, and they always end in tears. So the basic idea of Moya is that we want some network abstraction layer that sufficiently encapsulates actually calling Alamofire directly. It should be simple enough that common things are easy, but comprehensive enough that complicated things are also easy. If you use Alamofire to abstract away URLSession, why not use something to abstract away the nitty gritty of URLs, parameters, etc? After some setup, using Moya is really simple. Even cooler are the reactive extensions. Moya provides reactive extensions for ReactiveSwift and RxSwift.

Networking brings together URLSession, async-await (or Combine ), Decodable and Generics to simplify connecting to a JSON API. By providing a lightweight client that automates boilerplate code everyone has to write. By exposing a delightfully simple API to get the job done simply, clearly, and quickly. Getting swift models from a JSON API is now a problem of the past.

OmniEdge is an Open source p2p layer 2 , zero-config mesh VPN infrastructure, a traditional VPN, AWS VPC, Ngrok, DDNS alternative. No central server, easy to scale with less maintenance. What happens in intranet, stays in in intranet.