Mobile App for Intelligent SIM Selection, Automatic Failover and Multi-SIM Bonding

Title: Mobile App for Intelligent SIM Selection, Automatic Failover and Multi-SIM Bonding We are looking for a highly experienced mobile-networking developer to design and build an application that improves connectivity when national roaming is unavailable. The application should analyze the performance of available SIM/eSIM connections and determine which mobile network provides the best real-world quality and reliability. In addition to intelligent SIM selection, we want to investigate and implement simultaneous multi-SIM bonding or seamless failover wherever supported by the device and operating system. This is an advanced networking project, not simply a mobile user-interface project. Applicants must understand mobile connectivity, multiple network interfaces, traffic steering, tunnelling and session continuity. CORE OPERATING MODES 1. Intelligent SIM Selection The application should evaluate available SIM/eSIM connections using relevant radio and end-to-end performance indicators, including: - Signal quality - Network technology - Latency - Jitter - Packet loss - Upload and download performance - Connection stability - Recent disconnections - Internet and DNS reachability - Congestion - Data usage, quotas and cost - Battery consumption The application should: - Calculate a network-quality score - Recommend the most reliable network - Explain why a network is preferred - Avoid unnecessary switching - Maintain network-performance history - Allow configurable selection policies The developer must determine which measurements can be collected reliably and explain all hardware, operating-system, carrier and permission restrictions. 2. Automatic Failover When the active connection fails or falls below configurable thresholds, the application should switch traffic to the best available alternative wherever technically possible. The solution must: - Detect outages and degradation rapidly - Avoid failover caused by temporary fluctuations - Prevent repeated switching between similar networks - Maintain active sessions wherever possible - Handle IP-address changes - Return to the preferred network only after it becomes stable - Provide an assisted fallback when automatic switching is restricted The application must clearly indicate whether failover is automatic, assisted or unavailable on the current device. 3. Multi-SIM Bonding We want the developer to investigate whether two or more SIM/eSIM mobile-data connections can be used simultaneously on one mobile device. Where supported, the solution should combine the available mobile connections through a remote aggregation platform to provide: - Improved connection reliability - Continuity if one mobile network fails - Intelligent traffic distribution - Potential bandwidth aggregation - Dynamic adaptation to latency, jitter, loss and congestion - One stable logical connection for applications - Per-connection monitoring and statistics Expected operating policies include: - Performance mode - Reliability or redundancy mode - Balanced mode - Backup-only mode - Data-cost or quota-aware mode The developer must independently determine: - Which devices genuinely support simultaneous mobile-data connections - Whether compatibility depends on a specific chipset, model, regional version or firmware - Whether the operating system exposes the connections independently - Which permissions or commercial relationships are required - Whether the application can be distributed through official app stores - Which features require manufacturer or operator integration - What fallback behavior should be used on unsupported devices The application must not assume that every Dual SIM phone provides two simultaneous Internet connections. ADDITIONAL CONNECTIVITY OPTIONS The developer should evaluate whether the same architecture can support: - Wi-Fi and mobile data - Multiple mobile connections - A mobile connection and an external hotspot - A mobile connection and a tethered modem - Other network interfaces exposed by the device The application should automatically detect available connectivity options and display only the modes genuinely supported by the device. AGGREGATION PLATFORM If bonding requires a remote component, the developer must design and deliver the corresponding aggregation-server architecture. The proposal should explain: - The tunnelling and communication architecture - Traffic-distribution method - Session-preservation mechanism - Packet-ordering strategy - Handling of paths with different latency and bandwidth - Failure-detection mechanism - Encryption and authentication - Scalability - Monitoring - Deployment and operational requirements We are open to standard or proprietary approaches, but the developer must explain and justify the selected architecture. MOBILE APPLICATION INTERFACE The application should display: - Available SIM/eSIM profiles - Active mobile network - Quality score for each connection - Current operating mode - Connection status - Latency, jitter, loss and estimated capacity - Traffic transferred through each connection - Bonding contribution per connection - Failover and switching history - Data usage and quotas - Automatic and manual controls - Reasons for network-selection decisions - Device compatibility status - Clear explanations when a feature is restricted or unavailable ANDROID AND IOS The proposal must include separate feasibility analyses for Android and iOS. The applicant must identify: - What is possible through a normal consumer application - What requires additional permissions or entitlements - What requires manufacturer or operator cooperation - What depends on specific hardware - What can be published through official app stores - What cannot be implemented reliably - Whether the solution can carry all device traffic or only application-generated traffic Restricted or unsupported functions must not be simulated or presented as operational. MANDATORY FEASIBILITY PHASE The project must begin with a technical feasibility and proof-of-concept phase before complete application development. During this phase, the developer must: 1. Identify suitable commercially available test devices. 2. Identify the required SIM/eSIM and operator configuration. 3. Determine whether multiple independent mobile-data paths are simultaneously accessible. 4. Demonstrate independent traffic through each usable connection. 5. Determine whether traffic can be controlled separately for each connection. 6. Demonstrate the proposed failover mechanism. 7. Demonstrate simultaneous use of multiple connections wherever supported. 8. Measure throughput, latency, jitter, loss and continuity. 9. Document all hardware, firmware, permission and carrier dependencies. 10. Provide a clear Go/No-Go recommendation. Complete product development will proceed only after successful validation of the feasibility results. SECURITY AND PRIVACY The solution must include: - Strong traffic encryption - Secure application and server authentication - Certificate validation - Secure credential and token storage - Protection against DNS and traffic leaks - Minimal collection of subscriber information - User consent for measurements and VPN operation - Secure telemetry transmission and storage - Compliance with privacy and app-store requirements - Protection against unauthorized use of the aggregation platform DELIVERABLES - Technical feasibility report - Device and operating-system compatibility matrix - Hardware, firmware and permission requirements - Architecture and data-flow diagrams - Functional mobile proof of concept - Remote aggregation proof of concept, if required - Measured test results - Go/No-Go recommendation - Complete mobile application source code - Server-side source code - Build and deployment instructions - API and protocol documentation - Security documentation - Test plan and acceptance report - Production deployment recommendations - Known-limitations document ACCEPTANCE CRITERIA The project will not be accepted based only on a graphical interface, theoretical documentation or simulated network information. The proof of concept must demonstrate, wherever supported: - Measurements collected from real mobile networks - Correct identification of available subscriptions and connections - Independent verification of each Internet path - Real simultaneous traffic across multiple connections - Traffic continuity after one connection is interrupted - Accurate per-connection statistics - Stable switching without continuous oscillation - Clear behavior on unsupported devices - Reproducible installation and testing - Documented restrictions and dependencies The developer must not replace a second mobile connection with Wi-Fi without clearly disclosing and documenting the difference. REQUIRED EXPERIENCE Applicants should have strong, demonstrable experience in: - Mobile networking - Android and/or iOS connectivity frameworks - SIM/eSIM and cellular-network behavior - VPN or tunnelling applications - Multi-interface traffic management - Session continuity - Linux networking - Remote aggregation systems - Packet scheduling - Network measurement and monitoring - Mobile security - Production mobile application development QUESTIONS FOR APPLICANTS Please answer every question. Generic proposals will not be considered. 1. Can two SIM/eSIM mobile-data connections be used simultaneously on one Android device? Explain the exact conditions and limitations. 2. Can the same functionality be implemented on iOS? Clearly separate bonding, failover and assisted SIM selection. 3. Which commercially available devices would you select for the proof of concept, and why? 4. How would you verify that a device exposes two genuinely independent mobile Internet paths? 5. How would you ensure that traffic is transmitted through the intended SIM connection? 6. What permissions, system access, manufacturer support or operator cooperation may be required? 7. How would you design the bonding and aggregation architecture? 8. How would you preserve active sessions when one connection fails or changes its IP address? 9. How would you manage connections with significantly different latency, jitter, loss and bandwidth? 10. How would you prevent packet reordering or a poor connection from degrading the combined service? 11. Can the solution carry all device traffic or only traffic generated by the application? 12. How would you minimize battery and data consumption while continuously measuring network quality? 13. What is the most important technical risk in this project? 14. What must be proven before proceeding with complete development? 15. Please provide examples of relevant mobile-networking, VPN, tunnelling or multi-connectivity work. IMPORTANT We are seeking an engineer who will validate the concept honestly before proposing complete development. Applicants claiming that all Dual SIM smartphones automatically support simultaneous multi-SIM bonding, without explaining the hardware and operating-system restrictions, will not be considered. The proposal must clearly distinguish: - What is technically possible - What is possible only on selected devices - What requires privileged integration - What can be distributed commercially - What is not currently feasible